ПОЛЕЗНЫЕ СОВЕТЫ
Для многих компаний композитные приложения стали своего рода мостом для перехода к сервисно-ориентированной архитектуре (Service-Oriented Architecture, SOA). Интеграция таких прикладных систем позволила им продемонстрировать гибкость сервисов, созданных с применением Web или других технологий.
Напомним, что композитное приложение строится на базе существующих программ (таких как приложения SAP, выделенное хранилище данных или общедоступный Web-сервис), дополненных новой функциональностью и объединенных с помощью единого интерфейса. Главное заключается в том, что пользователь получает совершенно прозрачный доступ к информации независимо от сложности среды ее хранения.
Например, торговые представители могут использовать композитное приложение для автоматизации оформления заказа (см. рисунок). Через хорошо знакомый интерфейс системы управления отношениями с клиентом (Customer Relationship Management, CRM) продавец может проанализировать вероятность сделки, назначить и ввести расценки в программу управления заказами и даже проверить наличие товара на складе, чтобы сообщить покупателю, когда будет произведена отгрузка. Все это выполняется через единый интерфейс, который поддерживает функции чтения и записи, избавляя пользователя от необходимости изучать множество новых приложений.
ИТ-специалисты уже вывели определение композитных приложений. Такие решения рождаются в самых разных областях - в результате перестройки систем интеграции корпоративных приложений (Enterprise Application Integration, EAI), развития инструментальных наборов на базе корпоративных систем (скажем, SAP NetWeaver или Oracle Fusion) и при разработке прикладных сред с нуля.
Данные под рукой.Служба работы с покупателями и торговые представители
получают доступ к интегрированной информации в реальном времени
Но, похоже, сейчас данное определение начинает трактоваться более широко. Стираются границы между композитным приложением и "корпоративным смешением функций" (enterprise mashup). В результате распространенная в системе Web концепция "смешения" (например, совместное использование интернет-сервисов Ticketmaster и Google Maps для покупки билетов и выведения схемы проезда к концертному залу) переносится в область корпоративных вычислительных систем.
Почему разработчик должен отдавать предпочтение композитным приложениям, а не традиционным интеграционным подходам? Потому что, во-первых, такие приложения позволяют пользователям легко взаимодействовать в реальном времени с многочисленными системами, а во-вторых, в отличие от типичных интеграционных проектов их можно развернуть в течение нескольких недель.
Поскольку в каждой компании набор приложений создавался для поддержки ее бизнес-операций, службе ИТ приходилось все время заниматься интеграцией этих активов. Со временем ИТ-специалисты научились использовать для этого имеющиеся средства (такие как "извлечение, преобразование и загрузка данных" - Extraction, Transformation, Loading, ETL, заранее интегрированные пакеты приложений, EAI-продукты). А когда таких возможностей оказывалось недостаточно, они писали интеграционные программы вручную.
Web-сервисы обещают упростить эту задачу, особенно когда речь идет об обмене информацией между различными системами на синтаксическом уровне, а также позволить многократно использовать один и тот же программный код. Однако пока еще они ни самостоятельно, ни в сочетании с другими технологиями не способны обеспечить такую гибкость ИТ-инфраструктуры, чтобы ее можно было быстро адаптировать к изменениям бизнеса.
Композитные приложения, безусловно, обладают потенциалом для преодоления подобных препятствий и поэтому могут сыграть ключевую роль при организации корпоративной инфраструктуры. Однако очень важно, чтобы при их создании и развертывании программисты понимали некоторые основные проблемы.
Я всегда был горячим поклонником 12 оригинальных правил, сформулированных Тедом Коддом для реляционных баз данных. А теперь считаю нужным привести свои 10 правил для композитных приложений.
1. Ничего не упустите
Воспользуйтесь своими информационными активами независимо от их состояния и вида, даже если они находятся в процессе изменения. Это касается не только средств связывания данных и Web-сервисов. Вам необходимо добраться до уровня метаданных, специфических для каждой системы (например, настроек системы SAP на нужды конкретного предприятия). Я предпочитаю называть это анализом и извлечением информации.
| Торговые представители могут использовать композитные приложения для автоматизации оформления заказа. |
2. Будьте восприимчивы к изменениям
Вы должны иметь возможность использовать новые информационные активы без полной перестройки прикладных систем и бизнес-процессов. Композитные приложения нельзя скреплять намертво. Они должны меняться в соответствии с переменами в бизнесе. Поэтому нужно легко добавлять, исключать или модифицировать отдельные функции композитного приложения.
3. Не теряйте из виду смысл
Учитывайте семантические различия в рамках одного прикладного пакета приложений и в приложениях различных производителей. Семантические проблемы нужно решать в самом начале проекта интеграции. Например, что означает термин "имя клиента" для вашей компании и как определяют его ваши системы? Решив вопросы семантики, вы добьетесь, чтобы интеграция полнее соответствовала требованиям бизнеса. И вам не придется сталкиваться со скрытыми несоответствиями, которые способны причинить серьезный ущерб.
4. Действуйте быстро
Время создания решения имеет огромное значение. Сейчас оно измеряется несколькими неделями, а не месяцами и годами, как раньше. Не пытайтесь писать композитные приложения вручную или использовать продукты, не предназначенные для быстрой сборки прикладных систем. Ведь мы живем в постоянно меняющемся мире.
5. Ориентируйтесь на свою аудиторию
Вы должны уметь развертывать композитные приложения с учетом конкретных потребностей своих пользователей. Не следует заставлять сотрудников изучать новое ПО без особой необходимости. Это означает, что они должны сами выбирать подходящий канал доступа к информации ("тонкий" или "толстый" клиент либо встраивание новой функции в существующее приложение, такое как CRM-система или Microsoft Office).
6. Будьте осторожны
Не перемещайте данные без нужды. Ведь композитные приложения должны предоставлять пользователям прозрачный доступ к данным из других систем, избавляя их от трудностей, связанных с перемещением и копированием информации. Сейчас этот фактор приобретает особо важное значение в связи с ужесточением законодательных требований и необходимостью обеспечения защиты данных. Не стоит сбрасывать со счетов и вопрос сохранения общей целостности системы и простоты управления информацией. Ввод данных в несколько систем отрицательно сказывается на их качестве. Внесение в них любых исправлений требует затрат и может приводить к ошибкам.
7. Оставайтесь практичными
Строительными блоками для вашего приложения должны служить не просто Web-сервисы, а так называемые бизнес-сервисы. Первые скорее относятся к области коммуникаций, чем к интеграции. А вторые позволяют преодолеть присущие Web-сервисам трудности управления данными и операциями, так как приспособлены к конкретным бизнес-процессам, а также готовы для многократного использования и интеграции. Им нужно придать такую форму, чтобы сотрудники могли понимать их и работать с ними - например, разместить заказ или проверить состояние сделки.
8. Будьте гибкими
Чтобы композитное приложение было более гибким, оно должно работать не с данными, а с метаданными. Основные бизнес-сервисы и выделенные вами фрагменты существующих программ должны храниться в репозитории метаданных, желательно созданном на базе языка XML. Это позволит построить среду, в которой будет удобно работать с фрагментами кода, совершенствовать их, формировать и хранить бизнес-сервисы более высокого уровня, поддерживать связи между ними и, наконец, собирать само композитное приложение.
9. Позаботьтесь о защите
Сохраните все встроенные механизмы безопасности существующих у вас приложений и корпоративной системы в целом. Однако к ней придется добавить прозрачную инфраструктуру защиты композитного приложения. Механизмы обеспечения безопасности и аутентификации, интернет-протоколы с шифрованием и т. п. использовать нужно, но все это надо скрыть от пользователей, которые работают с бизнес-данными и бизнес-операциями.
10. Создайте рабочее окружение
Позаботьтесь, чтобы композитные приложения были совместимы с вашей сервисно-ориентированной архитектурой и могли взаимодействовать с другими важнейшими элементами корпоративной инфраструктуры. В противном случае вы рискуете лишь увеличить количество разрозненных компонентов. Вам следует оформить вышеупомянутые бизнес-сервисы в качестве Web-сервисов, тогда их можно будет встроить в любую основанную на Web-сервисах среду. Это подразумевает возможность взаимодействия с шиной ESB (Enterprise Service Bus), с инструментами управления бизнес-процессами (Business Process Management) и интегрированной средой разработки (Integrated Development Environment), а также с приложениями из пакета Microsoft Office, Web-страницами, порталами и мобильными устройствами.
Роджер Сипл является основателем и председателем правления компании Above All Software. Ему можно писать по адресу: roger.sippl@ aboveallsoftware.com.
