Как ответить на нелегкие вопросы отображения и синхронизации данных, синхронизации потоков работ и обработки транзакций.
Интеграторам и разработчикам приложений все чаще приходится решать вопросы, связанные с созданием приложений поддержки сотрудничества (collaboration), с созданием новых уровней промежуточного ПО, которые станут основой для проектирования бизнес-приложений следующего поколения. Это упростит задачу интеграции, которая сегодня решается с помощью написания индивидуальных API-интерфейсов. Этот уровень программного обеспечения позволит корпоративным пользователям объединить уже существующие системные компоненты в единое приложение поддержки совместной деятельности.
Но чтобы заставить все это работать, необходимо преодолеть ряд трудностей, связанных с преобразованием данных, координацией бизнес-процессов и обработкой транзакций. Сегодняшние технологии, базирующиеся главным образом на интерфейсах открытых систем (в частности, на XML), представляют собой переходный этап на пути к более широкому использованию интерфейсов и протоколов Web-служб. Но переход этот можно будет завершить лишь после того, как соответствующие средства — такие как протокол SOAP и язык WSDL — получат повсеместное распространение. А теперь давайте кратко рассмотрим некоторые основные задачи, которые необходимо решить, чтобы это стало возможным.
Преобразование и синхронизация данных
Несмотря на то, что многие унаследованные системы и пакеты прикладных программ поддерживают технологию XML, в них используются совершенно разные модели и схемы обработки данных. Например, определения «заказа» или «клиента» в самостоятельно разработанных компаниями приложениях обработки заказов и в системе управления цепочками поставок (supply-chain management, SCM) могут заметно отличаться друг от друга. Более того, на многих предприятиях полные словари данных поддерживаются лишь теми, кто принимает непосредственное участие в написании программного кода. Таким образом управление словарями бизнес-терминов — отображение и преобразование данных различных систем в единую согласованную схему — становится одной из самых серьезных задач, с которыми приходится сталкиваться разработчикам интегрированных прикладных платформ. В настоящее время формируются новые подходы к разработке программного обеспечения, предусматривающие фильтрацию и отображение данных, а также определение словарей. Компания Vitria Technology, например, предлагает подход с преобразованием на базе словаря и использования механизма корреляции. Он позволяет просмотреть тысячи документов, каждый из которых содержит тысячи терминов, и установить взаимное влияние этих терминов на основе определенных правил, которые впоследствии одобряются или отклоняются аналитиками.
Связанная с этим задача касается управления данными множественного происхождения. Например, как лучше объединить информацию в одно логическое представление с унифицированной архитектурой, сохранив при этом независимость источников данных? Поскольку данные приложений продолжают храниться и изменяться в исходной системе, новый уровень ПО должен позволять осуществлять их выборку «на лету» и своевременно переносить все изменения в первоначальную систему.
«Наш инструментарий помогает организовать динамическое объединение данных в самых разных условиях, — отметил технический директор компании Journee Software Роб Бошам. Компания Journee поставляет корпоративным клиентам инструментальные средства для определения логической модели данных на промежуточном программном уровне. — Она работает как база данных, но на самом деле ею не является. В действительности информация извлекается из базовых хранилищ в процессе работы программы».
Другие производители, в числе которых можно выделить компании Asera и WRQ, используют структурированные схемы XML, базирующиеся на стандарте XML Schema консорциума World Wide Web. Эти схемы обеспечивают унифицированное представление, формируя обобщенный интерфейс для приложений поддержки совместной работы, перемещая документы XML с определенной семантикой вместо самих данных, на которых они базируются.
Протоколы Web-служб еще более упростят разработку взаимодействующих приложений, предоставляя необходимые соглашения и форматы для определения интерфейсов, сообщений, типов данных и структур; привязывая сообщения к различным транспортным механизмам; обеспечивая форматирование и хранение метаданных. Но в то же время корпоративные клиенты и их поставщики могут своими силами достаточно эффективно решать при помощи XML стоящие перед ними задачи.
На перекрестках сотрудничества
Еще одним препятствием на пути создания приложений поддержки сотрудничества является отсутствие стандартов описания и настройки бизнес-процессов в различных системах. «В общем случае сегодня вместо создания монолитной системы вам предлагается связать целый набор отдельных приложений, — пояснил Бошам. — Таким образом, вопросы моделирования и организации протоков процессов приобретают еще большее значение. Как лучше организовать управление повторными обращениями и урегулировать вопросы, связанные с выходом из лимита времени? Как должны формироваться соглашения о качестве обслуживания? В условиях отсутствия стандартов многие предприятия вынуждены импровизировать, особенно в отношении приложений поддержки совместной работы, находящихся вне зоны действия межсетевого экрана».
«Приложения поддержки совместной работы, как правило, эксплуатируются в течение достаточно длительного времени, — заметил технический директор компании Asera Анил Нори. — Они проходят в своем развитии несколько этапов, предусматривающих вмешательство человека в бизнес-процессы. У каждого имеется своя собственная точка зрения на определение процедур и интерфейсов. В настоящее время в данной области не существует каких-то устоявшихся стандартов».
Разработка приложений поддержки сотрудничества по-прежнему предусматривает большие затраты интеллектуальных усилий человека.
Сюда входит и непосредственное общение с разработчиками, принимающими участие в создании приложений, и формулировка задач, решаемых при помощи этих приложений, вычленение обрабатываемых данных, определение моделей безопасности и авторизации и т.д.
Только после этого можно сформулировать общие правила и назвать бизнес-процессы, охватываемые данной системой. Для решения этих задач разрабатываются многочисленные стандарты, ориентированные в том числе и на вертикальный рынок. К ним относятся технологии Microsoft XLANG, IBM WSFL (Web Services Flow Language), а также проект BPMI (Business Process Management Initiative), реализацией которого занимаются сразу три участника. Технология ebXML (e-business XML) также имеет составляющие бизнес-процессов, но она базируется на объектной модели, вследствие чего ей недостает уровня абстракции для слабо связанных процедур. «Я со своей стороны жду появления чего-то очень простого, напоминающего XLANG, но при этом имеющего концептуальное значение, как WSFL», — заявил технический директор компании Iona Technologies Эрик Ньюкамер.
По мере развития соответствующих стандартов инструментальные средства создания приложений поддержки сотрудничества будут переориентированы в большей степени на разработчиков, чем на бизнес-пользователей, которые лучше разбираются в бизнес-процессах. «Сейчас мы переходим от языков программирования к языкам разметки, которые являются фактическим отражением понимания мира людьми, — пояснил Ньюкамер. — Ключ к созданию платформ поддержки сотрудничества приложений следует искать в предоставлении пользователям возможности отлаживать процедуры на уровне визуальной абстракции, а не на уровне сценариев XML».
И наконец, третий вопрос связан с поддержкой транзакций. «Самое сложное — приспособить модель обработки транзакций к особенностям базовых систем, — пояснил Бошам. — Если модель не работает в некоей системе, можно вернуться на уровень двух предыдущих».
Определения транзакций также должны быть связаны с определениями потоков процедур, с тем чтобы транзакции можно было «откатить» на соответствующий уровень модульности процедуры, которая, в свою очередь, должна быть привязана к уровню модульности модели безопасности. Одним из подходов к решению данной задачи является предложенный консорциумом W3C стандарт XA, предусматривающий блокировку в процессе обработки транзакции множеством систем, гарантирующую сохранение ее целостности. Однако некоторые крупные производители программного обеспечения, в частности, компания Siebel, до сих пор не поддерживают XA, мотивируя это отсутствием потребности со стороны клиентов.
Еще одним моментом, связанным со взаимодействием приложений на базе XML, является производительность транзакций. Архитектуры CORBA или Java RMI (Remote Method Invocation) при обработке большого объема транзакций могут оказаться эффективнее приложений XML, потому что текстовые документы XML занимают больше места. «Если вы выполняете миллионы подобных операций, возможно, вам захочется сохранять данные в двоичном формате, — отметил Бошам. — Но для большинства приложений уровень XML вполне приемлем».
Производители, поставляющие платформы для приложений поддержки сотрудничества, говорят об открытости своих архитектур промежуточного слоя и подчеркивают закрытый характер продуктов конкурентов и их несоответствие общепринятым требованиям. Однако все согласны с тем, что для выполнения поставленной задачи необходимо некоторое сочетание технологий — промежуточное программное обеспечения на базе XML, традиционные сообщения средств публикации и подписки и архитектуры Web-служб. Корпоративные пользователи хотят оптимизировать компоненты существующих приложений, вывести бизнес-логику на уровень промежуточного, а не конечного слоя, обеспечить независимость промежуточного слоя от специфических элементов управления производителя и исключить необходимость дорогостоящего написания клиентского кода для каждого нового приложения. Теперь все зависит от совместных усилий производителей по продвижению данной концепции.
Разгадка к головоломке сотрудничества
По мере роста у корпоративных пользователей потребностей во взаимодействии и в интеграции независимого от конкретного производителя ПО промежуточного уровня с целью сохранения инвестиций в уже существующие системы ведущие поставщики начинают проявлять все большую активность. Некоторые из них недавно уже представили свои новые архитектуры (в частности, Siebel Systems продемонстрировала платформы Universal Application Network, а SAP — xApps Architecture and Exchange Infrastructure), предназначенные для формирования среды сотрудничества.
Основную сложность здесь следует искать в деталях, особенно это касается функциональности, обеспечиваемой данными архитектурами, а также стандартов, на основе которых построены интерфейсы. Как только одна группа игроков отвоевывает определенный плацдарм на поле корпоративного программного обеспечения, крупнейшие поставщики, безраздельно властвующие в области средств интеграции приложений предприятия (enterprise application integration, EAI), прилагают все усилия к тому, чтобы сохранить и упрочить свои позиции на рынке.
В войне порталов это означает борьбу за «главный приз» — «приборный щиток предприятия», то есть экраны приложений, управляющие всей бизнес-логикой и процессами предприятия, а также связанными с этим данными. Сделать это будет еще труднее, если крупные поставщики ПО предоставят всем желающим неограниченный доступ к своему коду или службам.
В SAP и Siebel утверждают, что основой взаимодействия для них станет язык XML и протоколы Web-служб. Вице-президент Siebel по вопросам сетевых приложений Бхарат Кадаба говорит, что его компания намерена использовать в интеграционной платформе UAN (Universal Application Network), которая должна появиться осенью текущего года, уже существующие и перспективные стандарты XSLT (Extensible Stylesheet Transformation), WSFL (Web Services Flow Language) и свой собственный интерфейс XSD (XML Schema Definition).
Обе компании уже объявили о создании новых решений в области автоматизации бизнес-процессов, например, о квотах на заказ, которые позволят приложениям CRM и ERP взаимодействовать с приложениями конкурентов, а также с собственным программным обеспечением производителей и с унаследованными приложениями. Вопрос заключается лишь в том, какую часть собственного кода они готовы предоставить сторонним разработчикам.
Разработчики интерфейсов EAI заявляют, что интерфейсы независимых производителей не в состоянии обеспечить корпоративным пользователям необходимое им представление. Но в конце концов последнее слово остается за самими клиентами. «Независимые поставщики хотят по-прежнему диктовать условия, но клиентам нужно интегрироваться в процесс, — отметила вице-президент IBM по разработкам Мари Вик. — Производители интегрированных корпоративных решений заняты поиском стратегических установок, в частности, интегрированной инфраструктуры и промежуточного программного обеспечения для одновременного удовлетворения самых различных потребностей, а не только обеспечения функционирования индивидуальных узкоспециализированных продуктов».
Популярность растет
|
| Все больше пользователей осваивают средства организации виртуального сотрудничества для совместной работы над проектами, оптимизации взаимодействия бизнес-бизнес и разработки корпоративных продуктов. |