Введение
В организациях усиливается тенденция перехода от монолитных, статичных приложений к SOA (Service-oriented Architecture, сервисно-ориентированная архитектура), которая предполагает реализацию гибких и экономичных сервисов. Так обстоит дело во многих компаниях, входящих в список Fortune 500, в которых идут проекты модернизации унаследованных приложений. Ведь эти монолитные системы являются основой (ИТ-инфраструктуры) почти всех этих компаний.
Но хотя сервисы и представления о гибкости и переносимости являются основой наших дискуссий о путях разработки новых приложений в организациях, унаследованные приложения - это слон в посудной лавке. Что SOA означает для организаций, которые используют приложения, разработанные годы или даже десятилетия тому назад? Приложения, изменения которых стоят очень дорого и которые поддерживаются специалистами, которых становится все меньше … Это проблемы, с которыми приходится иметь дело каждому IT-менеджеру.
Эти монолитные системы - "сердце" банков, транспорта и производства по всему миру. Но организации должны постараться, чтобы не выплеснуть ребенка с водой при реализации новых подходов. В этой статье представлены несколько примеров того, как технологии Oracle могут использоваться для интеграции унаследованных приложений.
SOA в контексте
Термин SOA был использован и, возможно, даже переиспользован, до такой степени, что был дикредитирован среди людей, принимающих решения. Поэтому, прежде чем приступить к нашим примерам, разберемся, что SOA означает в терминах унаследованной среды мейнфреймов и ее модернизации.
Думайте о SOA как о концептуальном чертеже (framework) для построения приложений, а не как о наборе конкретных технологий или протоколов. SOA - это способ предоставления вычислительных ресурсов посредством "раскрытия" дискретных бизнес-процессов для использования потребителями. SOA больше, чем набор протоколов и технологий - таких как SOAP и WSDL или Java/RMI, - это чертеж (blueprint) для построения приложений. Web-сервисы - это одна из возможностей реализации этого концептуального чертежа. Другие технологии, которые можно использовать для реализации SOA - это движки (engines): Business Activity Monitoring (BAM) - мониторинга активности бизнеса, Business Process Execution Language (BPEL) - языка исполнения бизнес-процессов, Enterprise Service Bus (ESB) - корпоративной сервисной шины и Business Process Management (BPM) - управления бизнес-процессами. Технически, и FTP - это интерфейс в SOA!
Интегрируя SOA в среду унаследованных приложений
(Integrating SOA into a Legacy Framework)
Основная идея для обеспечения [встраивания в SOA] унаследованного приложения заключается в идентификации основных строительных блоков и точек доступа (access points) на мейнфрейме. Три главные проблемы интеграции в среду унаследованных приложений на мейнфрейме таковы:
- Презентационный слой (Presentation Layer): В данном случае нужно предоставить некоторый уровень сервиса потребителю, чтобы улучшить условия работы пользователю и расширить доступ к другим приложениям через программу, с которой он работает (front end).
- Бизнес-слой (Business Layer): Попросту говоря, это процедурный вызов (procedure call), обернутый (wrapped) в SOA-сервис. Как показано в примере ниже, это действительно может "раскрыть" (open up) унаследованное приложение для повторного использования и гибкости. Но это далеко не тривиальная задача. Также как и с унаследованными приложениями (на мейнфрейме иди другой платформе), бизнес-процессы часто не являются дискретными, выделенными (standalone) сервисами. После разработки в течение ряда лет типичное состояние исходного кода можно сравнить с большим клубком ниток. И определение начала или конца процесса может быть сложной задачей.
- Слой данных (Data Layer): SOA-сервис или вызов может быть сделан к хранилищу унаследованных данных (legacy data store) или файловой системе. Это позволяет пользователям использовать "родные" (native) вызовы к данным для доступа как к реляционным, так и не реляционным источникам данных. С интеграцией данных предприятия могут поддерживать полностью транзакционный, направленный в обе стороны (bidirectional), и с применением SQL доступ к любому хранилищу на мейнфрейме.
Интеграция на основе SOA: 4 главных сценария и решения Oracle
Технические журналы и IT-аналитики пришли к тому, что SOA - это не продукт или решение, а путешествие (journey). То есть, модернизация - это просто путешествие, для которого, однако, нужна дополнительная экипировка. В этом путешествии могут случиться неожиданные повороты, встретиться непредвиденные места, такие как бизнес-цели (business objectives), ключевой персонал и изменения технологий.
Информация, представленная здесь, основана на факторах и ситуациях, которые, мы полагаем, являются типичными для клиентов и партнеров, которым мы помогали в их путешествиях-модернизациях. Специфика каждой ситуации и среды - требования от людей бизнеса (business drivers), направление стратегии, рассматриваемые тактические решения или самая сложная проблема (biggest pain point) могут различаться. Но мы надеемся, что к концу этой секции на все вопросы о том, когда, где и как начинать (путешествие-модернизацию), будут даны ответы.
Продукты Oracle, включенные в решение
Семейство продуктов Oracle Fusion Middleware включает все необходимые компоненты для сервисно-ориентированной архитектуры на основе шины унаследованных сервисов- Service-Oriented Legacy Service Bus/SOA Integration architecture. Но прежде чем мы начнем, давайте рассмотрим, почему именно эти отобранные продукты нужны и почему не отобраны другие продукты.
Почему Web-сервисы?
Web-сервисы - это основа коммуникаций в данном контексте, также как и результаты обработки мейнфреймовых артефактов. Без Web-сервисов шина унаследованных сервисов и интеграция на ее основе - Legacy Service Bus/Legacy SOA Integration - невозможна. Этим все сказано (Enough said).
Почему Oracle Legacy Adapters?
Мы ссылается к Oracle Legacy Adapters как к движку унаследованных сервисов - Legacy Service Engine. Эти адаптеры обеспечивают плавный поток информации из среды унаследованных приложений в среду открытых систем.
Почему Oracle BPEL Process Manager?
Оркестровка бизнес-процессов и workflow (поток работ) с людьми-участниками - human workflow - необходимы для коммуникаций между шиной Legacy Service Bus (LSB) и мейнфреймом, между внутренними и внешними сервисами. Чтобы изменения в ИТ соответствовали изменениям в бизнесе, приложения должны быть более процессными. В современном мире workflow-движки размещают нужные задачи в workflow ящики (inboxes), избавляя пользователей от запоминания действий (activities), которые должны быть выполнены.
Oracle BPEL Process Manager позволяет быстро и легко оркестрировать имплементации SOA-сервисов, взаимодействие с человеком (human interaction) и системами (system workflow) с применением графической drag-and-drop техники, что поддерживает прямое вовлечение пользователя в системную оркестровку, тем самым сокращая объем требуемого заказного кодирования и увеличивая гибкость приложений.
Почему Oracle Enterprise Service Bus?
BPEL обеспечивает автоматизацию потоков работ, выполняемых как системами, так и людьми (business and human workflow) для бизнес-сервисов. Но многие сервисы являются общими для многих приложений. Сервисная шина поддерживает эти общие сервисы благодаря таким стандартным функциям, как обработка сообщений (messaging) и возможности интеграции, часто при этом инкапсулируя различные технологии, которые и реализуют эти общие сервисы, making them appear as one.
Oracle ESB предоставляет уровни обработки сообщений и интеграции для прямого соединения приложений и web-сервисов через общую инфраструктуру. Oracle ESB объединяет шину асинхронной обработки сообщений (asynchronous messaging backbone) с интеллектуальным преобразованием сообщений и маршрутизацией, чтобы гарантировать надежную передачу сообщений. Для мейнфреймов это обязательное условие, так как они известны качеством своих сервисов и надежностью.
Oracle ESB использует grid-возможности Oracle Application Server для формирования ESB-grid, которая пересекает множество платформ.
Почему Oracle Enterprise Manager (OEM)?
Ранее в этой статье обсуждалось, что в данной точке путешествия-модернизации не нужен специализированный менеджер web-сервисов - Web Services Manager или реестр web-сервисов - Web Services Registry. Однако, имеет смысл использовать технологии продукта Oracle Enterprise Manager для управления среднего слоя (middle-tier) SOA и, возможно, впоследствии Oracle Database Grid. SOA Management Pack также предоставляет средство для мониторинга Web-сервисов с точки зрения конечных пользователей и для мониторинга на основе запросов. Администраторы могут определять тесты SOAP для одного или более партнерских линков BPEL-процесса, любого web-сервиса на хосте или внешнего сервиса.
Почему Oracle Identity Management?
Каждая IT-среда нуждается в той или иной форме обеспечения безопасности. Путешествие под названием SOA Legacy Integration должно начинаться с обеспечения безопасности достаточно высокого уровня, но не слишком сложного для реализации и поддержки. Identity Management - это широкое понятие у Oracle. Оно включает все от обеспечения единого входа и однократного ввода учетных данных (single sign-on) до оптимизации установки/обновления ПО на множестве ПК (provisioning), интегрированной идентификации (federated identity), сервисов директорий, центра сертификации (certificate authority) и т.д. Вскоре мы будем использовать Oracle Internet Directory (запомните, оно называется OID и является директорией, соответствующей LDAP) и Oracle Enterprise Single Sign-On, чтобы обеспечить единый логин ко всем приложениям (web-сервисам).
Почему Oracle WebCenter Portal?
Портал предоставляет единую точку входа в среде web к ряду приложений. Использование портала позволяет организации сформировать уникальный пользовательский опыт по объединению многих функциональных компонентов SOA-приложений в единой точке доступа.
Почему Oracle Data Integrator?
Oracle Data Integrator (ODI) позволяет пользователям извлекать данные из многих унаследованных и не унаследованных источников. В том числе и с мейнфреймов, используя web-сервисы, которые являются частью LSB (шина унаследованных сервисов) сервера приложений. ODI может загружать и преобразовывать данные в различные приемники данных. Совместное использование информации плоских файлов часто является центральным звеном интеграции унаследованной информации. Замена этой обработки, разработанной по заказу, на продукт типа ODI централизует обработку плоских файлов и повышает ее гибкость и адаптируемость. Кроме того, такую систему намного легче расширять для обработки новых типов плоских файлов или для модификации текущих структур.
Почему Oracle Business Activity Monitoring (BAM)?
Современные системы не требуют завершения отчета, запроса или длительного пакетного процесса до предоставления информации об активности бизнеса. Наоборот, информация в реальном масштабе времени доступна через графические инструментальные панели (dashboards), которые могут посылать сигналы (alerts) через ряд коммуникационных механизмов, когда заданные пользователями пороговые значения превышены. Oracle (BAM) будет использоваться для обеспечения этой обратной связи в режиме реального времени для web-сервисов, BPEL- и ESB-процессов.
Почему Oracle Business Intelligence?
В качестве альтернативы печатных отчетов (hard copy reports), аналитические инструменты, включая инструменты класса data mining, работающие в режиме реального времени, могут использоваться для анализа (slice and dice) данных, чтобы определить ключевые индикаторы эффективности (KPI) и обнаружить тренды данных - и при этом не ожидать, когда отработают традиционные ИТ-средства. Это увеличивает гибкость организации в целом, позволяя конечным пользователям реагировать быстро и прямо на происходящие изменения в бизнесе.
Сценарий 1: Интеграция информации предприятия (EII)
Также известный как: интеграция данных (Data Integration), совместное использование файлов (file sharing), работа с файлами через очереди сообщений (file messaging).
Проблема
Нынешняя инфраструктура для интеграции информации хрупка, дорога и трудна в поддержке. Для нее характерны проблемы с отсутствием типового подхода по использованию work-flow, возможностей для обеспечения качества данных и профилирования данных, адаптированной логики преобразования (данных), уникальной для каждого источника данных, средств мониторинга в масштабе реального времени и возможностей быстро добавлять новые источники данных.
Контекст
Данные должны совместно использоваться с новыми системами, разработанными в среде открытых систем, и с системами на других мейнфреймах, внутренних и внешних для организации. У большинства унаследованных систем есть источники и приемники данных.
Силы
Изолированные (stand-alone) приложения и организации - это вчерашний день. Сейчас необходимо совместное использование информации приложениями и бизнесами.
Решение
Решение включает Oracle ESB, Oracle BPEL, Oracle Legacy Adapters, Oracle E-Business Suite Adapters и Oracle OEM, как изображено ниже:
Обзор сценария 1
Важной целью интеграции Legacy SOA Integration является не разрушение существующих унаследованных и других систем. В данном решении для этого предлагается не изменять источники данных.
Даже небольшие изменения в этих источниках могут привести к проблемам:
- Если (с этим источником) вовлечена третья сторона или даже внутренняя организация, но вне вашего контроля, то могут потребоваться месяцы для завершения изменений (источника)
- Даже источники данных, контролируемые внутри (организации), влияют на исходные системы, текущую обработку данных и целевые системы, так что даже небольшое изменение может вызвать каскадный эффект. Текущий источник данных должен остаться неизменным, он может скачиваться через FTP в некоторую директорию и, вероятнее всего, останется средством пакетного (batched) типа. Это решение требует применения Legacy Adapters и Oracle Messaging, так как они могут быть адаптированы при изменении бизнес-процессов.
Oracle ESB
Oracle ESB будет использовать файловые или FTP-адаптеры для чтения плоского файла и затем для преобразования этого файла к типовому (каноническому) XML формату. Исходя от источника этих данных, сообщение будут направлено к соответствующему Oracle BPEL процессу.
Oracle BPEL
Ранее упомянутые возможности workflow и обработки используются следующим образом:
- Oracle BPEL вызовет процесс на Java или Web-сервисах для выполнения проверки. Обработка данных этого процесса проверки может требовать обращений к базе данных Oracle для выполнения проверки на основе данных этой базы.
- После проверки имеет место обработка, зависящая от типа файлов. Это вызывает применение бизнес-правил (business rules) к входному файлу данных. Обработка согласно этим правилам может потребовать вызовы движка продукта Oracle Rules.
Обработка типичных ошибок
(Common Error Processing)
Ошибки, выявленные при проверке и/или обработке бизнес-правил, будут переданы соответствующей программе (error-handling route). Рабочий список в BPEL (worklist) будет заполнен и распространен, так что и люди могут принять участие в коррекции проблемного файла или записей.
Сохранение состояния данных Web-сервиса
(Data persistence Web service)
Эти данные будут храниться в базе данных Oracle или IMS database, и/или (в базе данных) Oracle E-Business Suite.
Сценарий 2: Web-изация интерфейса
(Web Enablement)
Также известный как: Screen Scraping, Re-interfacing.
Проблема
Специалисты по поддержке клиентов и продажам, клиенты и партнеры хотели бы получить доступ к вашей информационной системы через Web. Однако, нет единого интерфейса, через который можно было бы изменять и унаследованные приложения, и Oracle-системы.
Технологиям старых зеленых экранов свойственно немало ограничений, не последнее из которых - эти технологии не очень то интуитивны. Доступ к нескольким экранам или системам необходим, прежде чем получить доступ к нужной информации, но при этом нет возможности point-and-click. Кроме того, пользователи часто вынуждены обращаться к ряду систем, чтобы получить доступ или изменить одни и те же или похожие данные.
Контекст
Пользователи хотят свои данные сейчас, независимо от того, где они находятся, и в любое время дня или ночи. Пользователи также хотят, чтобы унаследованные приложения и новые Oracle-системы работали согласованно.
Бизнес-процесс, который требует от пользователя запрашивать и затем и изменять ряд систем, замедляет все и во многих случаях приводит к несогласованности данных (data inconsistencies).
Силы
Технологии, которые поддерживают более лучшие интерфейсы приложений, доступны на рынке в течение ряда лет. Но что еще важнее, они позволяют подключать пользователей продвинутых в отношении web, ряды которых продолжают расти.
Решение
Это решение включает Oracle WebCenter, JSF/JSP, Oracle Legacy Adapters и Oracle OEM, как показано ниже:
Обзор сценария 2
Ключ к этому сценарию - интерфейс. Следовательно, Oracle WebCenter и/или JSP/JSF будут использоваться. На первой итерации этого сценария JSP и/или JSF могут использоваться для упрощения разработки и убыстрения развертывания (приложений). Более сложная альтернатива - это использование JSF для разработки портлетов JSR-168, которые затем будут развернуты с применением Oracle WebCenter.
Сценарий 3: Перенос получения отчетов с мейнфреймов
(Report Off-Load Using Data Migration)
Известный также как: миграция данных (Data migration), операционное хранилище унаследованных данных (Legacy Operational Data Store), модернизация формирования отчетов (Reporting Modernization).
Проблема
IT-перспектива: Унаследованная инфраструктура формирования отчетов стоит миллионы (в части эксплуатации) и при этом может приводить к шестимесячным задержкам выполнения запросов на отчеты.
Пользовательская перспектива: Даже со 100 красивыми (100 green-bar) отчетами не хватает информации для принятия деловых решений.
Контекст
Пользователям нужен доступ к информации в различных форматах и измерениях. Они также нуждаются в легком создании нерегламентированных (ad hoc) и что-если (what-if) сценариев. И для организаций, которые делают ставку на мейнфреймы, несвойственно полагаться только на электронные таблицы при прогнозировании стратегических продаж.
Силы
Генерация отчетов на мейнфрейме дорога и создает барьеры между бизнес-пользователями и информацией, которая им необходима для принятия решений. В типичной организации пользователи создают свои собственные отчеты, используя Excel, SQL и другие инструменты ПК, что часто приводит к дублированию данных по всему предприятию.
Решение
Это решение включает Oracle Data Integrator, Oracle BPEL, Oracle Legacy Adapters, Oracle BAM, Oracle BI Suite и Oracle OEM.
Обзор сценария 3
В данном обзоре объясняются причины выбора продуктов Oracle, используемых в этом сценарии.
Oracle BAM
Используя продукт Oracle BAM, как конечные пользователи, принимающие решения, так и IT-менеджмент видят поток информации текущий в режиме реального времени в систему формирования отчетов. Конечные пользователи, принимающие решения, могут делать это в режиме реального времени на основе самой свежей информации. IT-менеджмент может получать сразу же сигналы (alerts), если загрузка данных идет медленно или о количестве данных, загружаемых каждую минуту, либо о среднем времени ответа при исполнении нерегламентированных (ad hoc) пользовательских отчетов.
Oracle BPEL
Oracle BPEL используется для оркестровки потока информации в базу данных Oracle, используемую для формирования отчетов. Oracle BPEL может использоваться для создания расписания загрузок данных на основе времени их прихода или времени прихода заданного файла или постоянного поиска порций данных для загрузки.
Oracle Data Integrator (ODI)
Oracle Data Integrator предоставляет быстрый метод загрузки больших массивов данных в базу данных Oracle, используемую для формирования отчетов. Он также предоставляет сервисы преобразования, очистки (cleansing) и управления данными. Так как ODI полностью построен согласно идеологии web-сервисов, любой компонент ODI может потребляться продуктами Oracle BPEL, Oracle ESB или любым другим средством, построенным по этой идеологии.
Oracle BI
Предыдущие продукты - это инфраструктурные продукты, которые нужно использовать для достижения основной цели: перенос процесса формирования отчетности с мейнфреймов для обеспечения доступа к нему всех пользователей. Продукты Oracle BI могут дополнять их, сокращая применение электронных таблиц Excel и отчетов с использованием SQL на пользовательских ПК.
Сценарий 4: полная SOA
(End-to-End SOA)
Также известный как: Software как сервис (SaaS), Legacy SOA Integration.
Проблема
Унаследованная система - это черный ящик. Ввод информации в нее - трудный процесс, но извлечение информации из нее еще труднее. Она не обеспечивает "видимости" бизнес-процессов, от которых зависит бизнес.
Контекст
Система на мейнфрейме не соответствует тому, как бизнес ведется сегодня. Эту унаследованную систему трудно поддерживать, она "сопротивляется" расширениям и является препятствием для развертывания новых сервисов/продуктов для внутренних и внешних пользователей.
Силы
Пользовательское сообщество требует обработки информации в режиме реального времени со сразу же доступными результатами. Интерфейсы интеграции с данными системы меняются каждую неделю и новые торговые партнеры хотят контакты (с вашей организацией) проходили в течение дней, а не месяцев. Интерфейсы системы должны быть персонализованными, чтобы реализовать доступ на основе ролей к соответствующей информации:
- Полный доступ для внутренних продвинутых (power) пользователей.
- Продавцам нужен доступ к ко всем данным, имеющим отношение к продажам.
- Клиентам нужен доступ к данным, относящимся к (их) заказам.
- Руководителям нужно в режиме реального времени самое свежее (up-to-the-minute) представление о бизнеса (business insight).
Решение
Это решение включает Oracle WebCenter, Oracle PBM, Oracle BPEL, Oracle Legacy Adapters, Oracle BAM, Oracle ESB, Oracle OID and SSO и Oracle OEM.
Обзор сценария 4
Также как и с другими сценариями в данном обзоре будут объяснены причины выбора продуктов Oracle, используемых в этом сценарии.
Oracle WebCenter
Oracle WebCenter обеспечивает быстрый и легкий способ создания персонализованных взглядов (views) на систему. WebCenter также предоставляет интеграцию с OID и SSO для авторизации и аутентификации пользователей, также как и способность проверки безопасности во всех частях системы. Ушли те дни, когда нужно было логиниться ко множеству систем. Также ушли те дни, когда нужны были два зеленых экрана для проверки данных. Теперь все данные в одной информационной web-панели (web dashboard).
Oracle BAM
BAM в данном случае играет большую роль по мере роста обработки. BAM облегчает мониторинг всех бизнес-процессов и сервисов, позволяя это делать за одним экраном.
Oracle ESB
Также же как ESB уже предлагалась в этой статье к использованию для миграции данных из других систем и в качестве интеграционной шины, она может использоваться для приема файлов двух различных форматов и обработки их в одном workflow.
Oracle OID and SSO
OID используется со всеми SOA-продуктами (BAM, ESB и BPEL), чтобы предоставить единый репозиторий данных о безопасности. SSO облегчает жизнь, реализуя доступ ко всем приложениям через единый login. Пользователи, подключающиеся к одному приложению, одновременно проверяются (на доступ) ко всем другим.
SOA Integration: заключительный обзор
В данной статье показано, как среда унаследованных приложений может быть интегрирована в современные и будущие системы. Примеры и технические приемы, представленные здесь, - это только немногие из возможностей. Авторы (этой статьи) более подробно рассматривают эту тему в книге Oracle Modernization Solutions (Packt Publishing, ISBN: 1847194648).