Расширяемая распределенная интеграционная система приложения для предприятия

Номер патента: 3744

Опубликовано: 28.08.2003

Авторы: Гордон Гэри Алан, Йи Хон-Сью, Тейлор Джон Тимоти

Скачать PDF файл.

Формула / Реферат

1. Система интеграции множества компьютерных приложений, включающая

систему передачи сообщений предприятия, предназначенную для передачи сообщений между указанными компьютерными приложениями;

систему хранения баз данных, соединенную с системой передачи сообщений предприятия, предназначенную для хранения множества конфигураций преобразования данных и множества правил;

интеграционный сервер, соединенный с указанной системой передачи сообщений предприятия, включающий процессор преобразования данных, использующий конфигурации преобразования данных, хранящиеся в системе хранения баз данных, и процессор оценки правил, использующий правила, хранящиеся в системе хранения баз данных;

множество интерфейсных модулей, соединенных с указанной системой передачи сообщений предприятия, причем каждый интерфейсный модуль соединен с соответствующим компьютерным приложением, и каждый интерфейсный модуль производит обмен сообщениями между системой передачи сообщений предприятия и соответствующим компьютерным приложением и

интерфейсные модули, анализирующие индивидуальные элементы сообщения, полученные от компьютерных приложений согласно определению структуры сообщения.

2. Система по п.1, в которой указанный интеграционный сервер предназначен для разделения и составления комбинации сообщений, полученных от системы передачи сообщений предприятия, и выполняет основанную на содержании сообщений маршрутизацию сообщений к компьютерным приложениям.

3. Система по п.1, где каждый интерфейсный модуль преобразует сообщения, передаваемые от указанной выше системы передачи сообщений предприятия к соответствующим компьютерным приложениям, из системного формата в формат соответствующего компьютерного приложения, и преобразует сообщения, передаваемые от соответствующего компьютерного приложения для системы передачи сообщений предприятия, из формата соответствующего компьютерного приложения в системный формат.

4. Система по п.1, где каждый интерфейсный модуль передает сообщения между другими интерфейсными модулями и соответствующим ему компьютерным приложением.

5. Интерфейсный модуль для использования в системе интеграции приложений для предприятия, которая интегрирует множество приложений для предприятия, включающий

интерфейс, сконфигурированный для одного приложения, выбранного из приложений, существующих на предприятии,

компьютер, являющийся хостом указанного выше интерфейса;

структуру сообщений для каждого из множества сообщений, которые интерфейс создает, получает или на которые отвечает;

средства для соединения указанного интерфейса с выбранным приложением для предприятия и

средства для реализации указанного интерфейса с использованием указанных средств для соединения.

6. Интерфейсный модуль по п.5, где интерфейс выбран из группы, состоящей из интерфейса источника, интерфейса назначения, интерфейса ответа и интерфейса запроса.

7. Интерфейсный модуль по п.6, где интерфейс включает интерфейс источника и дополнительно включает средства для определения выбранных объектов из множества объектов назначения, которым интерфейс источника сконфигурирован посылать одно или несколько сообщений.

8. Интерфейсный модуль по п.6, где интерфейс включает в себя интерфейс назначения и дополнительно включает средства для определения тех источников сообщений, выбранных из множества, для которых указанный выше интерфейс назначения адаптирован для получения одного или более сообщений.

9. Интерфейсный модуль по п.6, где интерфейс включает в себя интерфейс ответа и дополнительно включает средства для определения объектов, выбранных из множества запрашивающих объектов, для которых интерфейс ответа адаптирован для отправления одного или более ответных сообщений.

10. Способ передачи сообщений между двумя компьютерными приложениями, включающий этапы

получения первого сообщения, обладающего данными первого компьютерного приложения;

публикации первого сообщения для получения опубликованного сообщения от первого приложения;

преобразования данных первого опубликованного сообщения от первого приложения в данные сообщения для второго приложения;

публикации второго сообщения для второго приложения и

получения вторым приложением сообщения, опубликованного для данного приложения.

11. Способ по п.10, дополнительно включающий этапы

преобразования сообщения от первого компьютерного приложения из формата этого приложения в системный формат перед опубликованием этого сообщения для рассылки; и

преобразования указанного выше второго опубликованного сообщения из системного формата в формат другого указанного выше компьютерного приложения перед получением этого сообщения данным компьютерным приложением.

12. Способ по п.11, где этап преобразования данных сообщения от первого компьютерного приложения включает

запрос структуры данных для второго приложения из базы данных и

получение структуры данных для второго приложения из базы данных.

13. Способ по п.12, дополнительно включающий этапы

обеспечения интерфейса, сконфигурированного для выбранного компьютерного приложения;

передачи данного интерфейса компьютеру, являющемуся хостом для данного интерфейса;

определения структуры сообщения из множества сообщений, которые интерфейс будет производить, получать или на которые отвечают; и

подключения интерфейса к выбранному компьютерному приложению.

14. Система интеграции приложений для предприятия, которая интегрирует множество приложений для предприятия, каждое из которых имеет соответствующий собственный формат для создания, посылки, получения, сохранения и обработки множества сообщений, включающая

интерфейсный модуль, имеющий множество интерфейсов, включенных в его состав, причем каждый из этого множества интерфейсов предназначен для выполнения дискретной функции.

15. Система по п.14, где первый из указанного выше множества объектов дополнительно включает средства для управления соединениями между интерфейсными модулями, подключенными к приложениям, выбранным из множества приложений предприятия, и к системе.

16. Система по п.14, где второй из указанного множества объектов дополнительно включает средства для обработки ошибок, обнаруженных в интерфейсных модулях, подключенных к приложениям, выбранным из множества приложений предприятия, и к системе.

17. Система по п.14, где третий из указанного множества объектов дополнительно включает средства для управления преобразованием множества сообщений в интерфейсных модулях, подключенных к приложениям, выбранным из множества приложений предприятия, и к системе.

18. Система по п.14, дополнительно включающая множество узлов и множество системных служб, находящихся на данных узлах.

19. Система по п.18, где каждый из множества объектов сконфигурирован для выполнения соответствующей функции на любом узле из вышеуказанного множества узлов.

20. Система для интеграции множества компьютерных приложений, включающая

систему передачи сообщений предприятия, которая передает сообщения между упомянутыми компьютерными приложениями;

систему хранения баз данных, соединенную с системой передачи сообщений предприятия, которая хранит множество конфигураций преобразования данных и множество правил;

интеграционный сервер, соединенный с системой передачи сообщений предприятия, причем интеграционный сервер включает процессор преобразования данных, использующий конфигурации преобразования данных, хранящиеся в системе хранения баз данных, и процессор оценки правил, использующий правила, хранящиеся в системе хранения баз данных; и

множество интерфейсных модулей, соединенных с упомянутой системой передачи сообщений предприятия, причем каждый интерфейсный модуль соединен с одним из упомянутых соответствующих компьютерных приложений и каждый интерфейсный модуль передает сообщения между системой передачи сообщений предприятия и соответствующим компьютерным приложением.

21. Система по п.20, дополнительно включающая

структуру сообщения, содержащую множество элементов сообщеэшщ;

множество средств доступа, каждое из которых сконфигурировано с одним из выбранных компьютерных приложений; и

множество конвертеров, каждый из которых сконфигурирован с одним из выбранных компьютерных приложений, и сконфигурирован таким образом, чтобы быть соединенным с выбранными средствами доступа из упомянутого множества средств доступа;

причем выбраны элементы сообщений из упомянутого множества элементов сообщений, соответствующих одному из упомянутых выше компьютерных приложений, так, чтобы к ним имелся доступ и их могли конвертировать для связи с другим из упомянутых компьютерных приложений.

22. Система по п.21, в которой упомянутое множество средств доступа и упомянутое множество конвертеров распределены в системе.

Рисунок 1

 

Текст

Смотреть все

1 Предпосылки создания изобретения Область изобретения Настоящее изобретение относится, большей частью, к тому, что известно в компьютерной сфере как "промежуточное программное обеспечение", и в частности к расширяемой распределенной системе и ее способам работы для интеграции таких приложений, которые обычно развертываются на предприятии с сетевой структурой. Уровень техники Согласно наблюдениям, если "кровью" сегодняшних корпораций является информация,то их "артерии" - это "межпрограммные интерфейсы", которые облегчают движение данных в информационной среде корпоративного предприятия. Это в последнее время стало известно как "сеть приложений". Для типичной компании сеть приложений органически выросла в коллекцию специальных программ, которые составляют набор интегрированных приложений. Этот разнобой имеет очень серьезное воздействие на бизнес, поскольку он увеличивает время внедрения новых приложений, мешает высшему руководству получать ясную картину бизнеса и, короче говоря,забивает корпоративные артерии. Несмотря на то, что интеграция приложений стала решающим фактором для выживания конкурентоспособной корпорации, все же раньше было допустимо использовать написанные вручную или"хакерские" специализированные программные коды для этих целей, что влекло за собой огромные долгосрочные потери. Более того, долгосрочные решения интеграции приложений были выполнены на самых низких возможных уровнях, основанных исключительно на индивидуальных проектных критериях. Из-за несомненной сложности этих проблем решение эффективной интеграции приложений для предприятия (enterprise application integration) (EAI) еще предстоит найти. Появление Интернета, вычислений клиент/сервер, корпоративных слияний и приобретений, глобализации и повторных разработок бизнес-процесса сообща вынудили корпоративные отделы информационных технологий (ИТ) непрерывно разыскивать новые, и зачастую ручные, способы заставить различные системы общаться друг с другом, независимо от срока существования некоторых из этих систем. В получившемся хаосе неадекватные связи ослабляли возможности ИТ, и они не распространяются так быстро, как это необходимо для бизнеса. Недавние тенденции в ИТ только обострили эту проблему, увеличивая, часто на порядок,количество межпрограммных интерфейсов, которые необходимо поддерживать. С недавних пор приложения для предприятия выполняют такие функции, как хранение информации(enterprise resource planning - ERP) и облегчают электронную торговлю (custom relationshipmanagement - CRM). Краткий обзор этих трех технологий был бы, следовательно, полезен для понимания давно ощущаемой, но пока еще нерешенной потребности в EAI. Технологии информационных хранилищ требуют больших объемов достоверных архивных данных, которые необходимо регулярно перемещать от многих действующих систем в хранилище. Исходные данные обычно структурируются для интерактивной обработки транзакций (online transactional processing - OLTP), в то время как типичное информационное хранилище также размещает форматы интерактивной аналитической обработки (online analytical processing OLAP). Поэтому исходные данные должны подвергаться обширному объединению и переформатированию при их передаче в хранилище. Из уровня техники известно, что типичное информационное хранилище заполняется за четыре этапа: (а) извлечение исходных данных;(b) очистка этих извлеченных данных; (с) объединение очищенных извлеченных данных в нескольких измерениях; и (d) загрузка хранилища. Каждый источник хранилища требует формирования определенной программы извлечения данных, их очистки, объединения и загрузки.Forrester Research оценивает, что, в среднем,большая компания имеет приблизительно четыре информационных хранилища. Ожидается,что через 2 года это число вырастет до шести. Среднее количество данных, содержащихся в каждом хранилище, как ожидается, удвоится за этот период от приблизительно 130 до приблизительно 260 Гбайт. Проблемы, связанные с такими большими объемами данных, возрастающими в постоянно увеличивающемся темпе, усугубляются качеством исходных данных. Согласно исследованию,проводимому МЕТА Group, типичные информационные хранилища загружаются сегодня на целых 20% данными низкого качества. Это исследование указывает, что приблизительно 70% его респондентов используют процессы извлечения, очистки и загрузки, которые были закодированы вручную. Относительно требуемых процессов объединения, пример показывает, что для завершения только одной этой функции может потребоваться целых 50 ч компьютерного времени. Очевидно, программы, закодированные таким образом, требуют существенных поддерживающих усилий. С другой стороны, типичные системы ERP(типа R/3 приложения для предприятия, разработанного SAP AG Walldorf, Германия, так же как и разработанные PeopleSoft, Oracle и Baan),по существу, являются большими, интегрированными пакетными приложениями, которые поддерживают основные функции бизнеса, такие как фонд заработной платы, производство,общий бухгалтерский учет и людские ресурсы. 3 Большие корпорации находят привлекательным покупку таких программных решений из единственного источника, так как для разработки тех же самых функциональных возможностей самостоятельно может потребоваться в 10-20 раз больше времени, чем при их покупке. Однако внедрение системы ERP может быть разорительным процессом по ряду причин. Прежде всего, корпорация покупает продукт, но не создает решение. Это означает, что подразделения корпорации должны адаптироваться к продукту и его работе, а не наоборот. Кроме того, сегодняшние системы ERP не могут заменить специализированные решения всей корпорации. Поэтому они должны эффективно поддерживать связь с другими имеющимися на месте старыми системами. Наконец, достаточно типично для корпорации использовать не одну,а несколько, и к тому же совершенно различных систем ERP, потому что единственный производитель не может обычно удовлетворить каждую организационную потребность. В результате, опции для ввода и вывода данных из системы ERP препятствуют известным подходам, используемым для информационных хранилищ. Каждая система ERP имеет собственную модель данных, которая постоянно улучшается ее поставщиком. Программы записи, извлечения или загрузки, которые манипулируют такими моделями, не просто сложные,но и еще усложняются поставщиком, поскольку проверка правильности данных и правила бизнеса, свойственные приложению для предприятия, скорее всего, будут обойдены. Вместо этого, ERP требуют взаимодействия на уровне бизнес-объектов, который имеет дело с определенными категориями бизнеса вроде общего бухгалтерского учета, бюджетов или оплаты счетов. Дальнейшие подробности относительно реализации и использования одной известной и широко распространенной системы ERP могут быть найдены в Special Edition Using SAP R73(1997). Электронная торговля в той или иной форме существует много лет. В сущности, она началась с электронного обмена данными (electronicdata interchange - EDI). EDI позволил компаниям передавать их заказы на поставку и счетафактуры в электронном виде и продолжал развиваться так, что сегодняшние компании используют EDI для управления цепочкой снабжения. Однако только при недавнем взрыве активности использования интерактивных Интернет web-сайтов для покупки, продажи и даже выставления на аукцион представляющих интерес предметов появилась сильнейшая потребность в устойчивом, эффективном EAI. См.,например, патент США 5627972. Приложения развиваются для выполнения определенной цели бизнеса в течение какого-то временного интервала. В типичной большой 4 компании различные команды людей, использующие широкий выбор операционных систем,систем управления базами данных (databasemanagement system - DBMS) и инструментальных средств разработки, разрабатывают сотни приложений. В каждом случае удовлетворяются определенные требования, не принимающие во внимание интеграцию с иными приложениями. Несколько мощных тенденций направляют рынок интеграции приложений. Например, существенные разработки для одноранговых сетей при распределенной обработке обеспечили предпринимателей возможностью лучшей интеграции их собственных функциональных отделов, так же как и интеграцией с их партнерами и поставщиками. Вышеупомянутый взрыв активности использования Интернета/Интранета также усиливает спрос на новый класс "человечески активных" приложений, которые требуют интеграции со старыми серверными программами. Огромный рост внедрения во всем мире программных пакетов приложений для предприятия (например, SAP R/3) также требует интеграции со старыми серверными приложениями. Наконец, продукты промежуточного программного обеспечения, ориентированного на сообщения (message oriented middleware - MOM),такие как продукт организации очереди сообщений IBM MQSeries, становятся все более и более популярными. Как только клиенты почувствуют выгоды от простой связи "один с одним" приложений с MOM, их интерес к интеграции приложений "многие со многими" значительно возрастет. Поскольку растет потребность в интеграции различных видов бизнеса, число долларов,потраченных на информационные потребности предприятия в части затрат на интеграцию приложений, быстро возрастает. Согласно различным промышленным анализам потребность в интеграции приложений "для решения ответственных задач" приведет объединенный рынокMOM и "брокеров сообщений" к росту от 300 млн долларов в 1997 г. до 700 млн долларов в 1999 г. Согласно обзору IBМ для крупных клиентов почти 70% всего написанного сегодня кода состоит из интерфейсов, протоколов и других процедур для установления связи между различными системами. Опытные администраторы ИТ отчетливо видят долларовую экономию, которую можно получить, приобретая имеющееся в наличии программное обеспечение для наиболее полного удовлетворения этой потребности. Брокер сообщения является программным концентратором, который записывает контракты между издателями (т.е. отправителями) и подписчиками (т.е. получателями) сообщений и управляет ими. Когда происходит бизнессобытие, приложение публикует сообщение(я),соответствующее(ие) этому бизнес-событию. Брокер просматривает свои списки подписки и 5 активизирует доставку каждому подписчику сообщения такого типа. Подписчики получают только те данные, на которые они подпишутся. На сообщение, опубликованное одним приложением, может подписаться множество приложений-потребителей. Точно так же приложениеподписчик может получать сообщения от множества приложений-издателей. Прежде чем приложения могут опубликовать сообщения или подписаться на них, они должны зарегистрировать их интерес у брокера. Для приложений имеются два основных и различных способа регистрации интереса к типу сообщения - адресация на основе темы и фильтрация содержания сообщения. При адресации на основе темы брокер использует тему для идентификации и направления сообщения всем сторонам, выражающим интерес к этой теме. Тема это слово, которое используется для описания содержания сообщения. Например, тема имени"hr.emp.new," может служить для распространения информации (например, имя, адрес, номер служащего и т.д.) о недавно нанятом служащем. При маршрутизации содержания сообщения, с другой стороны, подписки выполняются на основе содержания полей в пределах сообщения. Подписки могут быть основаны на типе сообщения и/или на определенном критерии выбора относительно поля в пределах сообщения. Например, приложение одобрения ссуды может подписаться на все заказы на поставку, превышающие 100000. Одним из преимуществ наличия двух парадигм публикации/подписки является то, что отпадает необходимость адресовать сообщения приложениям подписки индивидуально. Вдобавок, новые приложения подписки могут быть добавлены без каких-либо изменений приложения-издателя. Типичный брокер публикации/подписки использует устойчивое средство доставки для фактического распределения сообщений между приложениями. При прохождении ответственных сообщений по комбинации внешних и внутренних сетей программное обеспечение систем гарантирует, что сообщения никогда не будут потеряны или продублированы в случае сетевых отказов. Чаще всего, обеспечивается асинхронная возможность доставки сообщений,которая использует организацию очереди сообщений с промежуточным накоплением. В этой парадигме имеет место перемещение "от очереди к очереди" в псевдореальном времени, когда приложение подписки доступно. Если приложение подписки недоступно, сообщение сохраняется в устойчивой очереди для более поздней доставки. Чтобы быть эффективным, средство доставки сообщений должно включать функцию координации бизнес-транзакций. Бизнестранзакция обычно составляется из нескольких элементарных операций. Для осуществления 6 транзакции каждая элементарная операция должна завершиться успешно. Если даже одна элементарная операция завершилась неуспешно,то вся транзакция завершилась неуспешно, и тогда все завершенные элементарные операции должны быть возвращены назад. Эти транзакции выполняются долго и требуют основанных на сообщениях модификаций многочисленных баз данных. Функция координации бизнестранзакций обеспечивает эту управленческую поддержку. Двумя другими важными компонентами являются основанный на правилах процессор и компонент преобразования данных. Процессор бизнес-правил позволяет компаниям обрабатывать сообщения, основанные на уникальных требованиях их бизнеса. Как правило, процессоры бизнес-правил обеспечивают визуальный внешний интерфейс для того, чтобы избежать необходимости программирования на процедурном языке. Благодаря этому гибкому подходу изменения в процессах бизнеса могут быть легко отражены в изменяемой конфигурации правил. Компонент преобразования данных используется для разработки специфических для приложения адаптеров. Эти адаптеры конвертируют форматы данных и семантику приложений от приложения-отправителя для приложенияполучателя. Имеется много конверсионных требований. Они распространятся от основного преобразования данных до разрешения несовместимости, которая существует между структурой (т.е. синтаксисом), значением (т.е. семантикой) и временными соотношениями информации, которая должна совместно использоваться. Из уровня техники известны две основные стратегии для адаптеров приложения. Одна стратегия состоит в том, чтобы конвертировать все исходные данные и синхронизировать приложения к стандартной канонической форме. Сообщения перемещаются от адаптера источника на синхроадаптер в этой стандартной форме. В синхроадаптере сообщения конвертируются к формату синхроприложения. Вторая стратегия для адаптеров приложения заключается в том, чтобы автоматически конвертировать формат и семантику приложения-отправителя для приложения-получателя за один этап, без каких-либо промежуточных форматов. При этом подходе требуется только один адаптер для связи друг с другом двух приложений, и он может быть интегрирован с любым из приложений. Основанный на правилах процессор и компонент преобразования данных работают совместно для согласования различий между приложениями. Например, прежде чем два приложения могут быть интегрированы относительно заказов, должны быть определены бизнес-правила обработки заказов в каждой систе 7 ме. В приложении "А" заказ может быть составлен из набора данных от множества файлов и баз данных, тогда как в приложении "В" заказ может существовать в виде индивидуального сообщения, вложенного в большой файл бизнестранзакций. Сложной задачей является разрешение несовместимости между структурой данных и внутренним содержанием заказа, определенных в каждом приложении. Имеется множество потенциальных выгод для бизнеса, которые обеспечиваются брокером сообщений. Прежде всего, это легкость интеграции приложений. С брокерами сообщений интеграция новых приложений с существующими старыми или сторонними приложениями может быть выполнена за более короткое время. Интеграция может осуществляться без необходимости понимания внутренней структуры и дизайна каждого приложения. Сосредотачиваясь на интерфейсе сообщений, существующие приложения могут быть интегрированы с минимальным разрушением. Поддержка электронной торговли является второй выгодой, которую обеспечивает брокер сообщений. Поскольку предприниматели начинают автоматизировать цепочку снабжения их производителей и партнеров, имеется потребность в независимых приложениях для них для соединения слабосвязанным образом. Это является сущностью и силой брокера сообщений. Брокер сообщений полностью подходит для потребностей бизнеса. Последним, но, конечно, немаловажным,является поддержка брокером сообщений непрерывной разнородности. По мере того, как развиваются новые технологии, разрабатываются новые архитектуры и разнородность увеличивается с течением времени. Методология брокера сообщений разработана для приспособления к сегодняшнему разнородному миру и будет полезна в будущем. Различные новые приложения могут быть добавлены через какое-то время как издатели или как подписчики, без любых изменений существующих приложений в брокере сообщений. В итоге, брокеры сообщений обладают потенциалом, обеспечивающим подход "наименьшего общего делителя" для интегрирования неоднородных приложений в пределах предприятия. Пользователи могут выбирать лучшую технологию для каждого индивидуального приложения Java (зарегистрированная торговая марка Sun Microsystems, Inc., Mountain View,California U.S.A.), ActiveX (зарегистрированная торговая марка Microsoft Corporation, Redmond,Washington U.S.А.) или CORBA (зарегистрированная торговая марка Object ManagementGroup, Inc., Framingham, Massachusetts U.S.А.),без заботы о том, как это приложение интегрируется с другими приложениями в предприятии. Брокеры сообщений, таким образом, заполняют промежуток между приложениями будущего и 8 разнообразными и сложными продуктами и технологиями, которые в настоящее время существуют в сегодняшних каталогах приложений. В то время как имеется много выгод для принятия стратегии брокера сообщений, следует иметь в виду, что имеются также потенциальные ловушки. Большая сила брокера сообщений в терминах его гибкости слабой связанности может также быть его самой большой слабостью. Характер программного обеспечения брокера сообщений, как отмечено выше, очень универсален. Поскольку оно разработано для обработки многочисленных разнообразных условий,тестирование всех возможных сквозных путей кода является непреодолимой задачей. При наличии необнаруженных ошибок в программном обеспечении сообщения могут быть потеряны,доставлены дважды или задержаны. Повреждения от таких "несчастных случаев" наиболее остро почувствовали бы на предприятиях, где брокеры сообщений используются для интеграции ответственных приложений обработки транзакций. В финансовых транзакциях, например, доставка одного-единственного сообщения может стоить миллионы долларов, в то время как его недоставка или задержанная доставка может приводить к потере миллионов. Вторым риском при реализации брокера сообщений является возможность того, что иностранные приложения представят несанкционированные сообщения брокеру. Это также может приводить к потерям. Например, в банковской деятельности могут быть опубликованы поддельные сообщения, вызывая тем самым изъятие или незаконное присвоение фондов. Третьим риском при реализации брокера сообщений является классическое "единственное уязвимое звено". Брокеры сообщений прототипа типично реализуются архитектурой "общения концентраторов". Это означает, что большая часть графика сообщений проходит через несколько центральных концентраторов. В случае выхода из строя или физического повреждения одного из этих концентраторов ответственные бизнес-операции могут оказаться в состоянии аварийного останова. Другой проблемой распределенных концентраторов является трудность управления комплексом брокеров сообщений. Поскольку брокер сообщений интегрирует очень много различных бизнес-приложений на нескольких объединенных концентраторах, талант и опыт,требуемые для управления и администрирования комплексом брокеров сообщений, могут быть не найдены. Подверженность потенциальному риску велика всякий раз, когда технология применяется к ответственным приложениям обработки транзакций предприятия. Одна из проблем брокера сообщений состоит в том, что он манипулирует ответственной информацией. Условно 9 говоря, брокер сообщений довольно нов. Однако, несмотря на то, что некоторые компании,уже принявшие концепцию брокера сообщений,достигли большого успеха, необходимо гораздо большее, прежде чем брокеры сообщений и EAI смогут стать господствующей тенденцией. В 1980-х годах разработка систем программного обеспечения концентрировалась на способности разнородных систем связываться друг с другом. Это происходило в большой степени из-за быстрого увеличения оригинальных коммуникационных протоколов. Любая вновь разрабатываемая система была вынуждена либо подчиняться форматам приложений и данных имеющихся систем, с которыми она хотела бы соединяться или взаимодействовать, либо обеспечить такое приложение определенным преобразованием. Соответственно все программное обеспечение было в большей или меньшей степени специализировано. В сегодняшней быстро изменяющейся среде совместные усилия тысяч разработчиков по всему миру сосредоточены для разработки системы, которая удовлетворяет потребность в связи друг с другом совершенно различных приложений без необходимости включения множества специфически настроенных для приложений схем преобразования. Эта пока еще неосуществленная потребность основана на императиве глобальной экономии. Краткое описание изобретения Таким образом, основной целью настоящего изобретения является обеспечение системы и способов интеграции приложений для предприятия, которые в то же время обеспечивают всестороннее управление такими приложениями для предприятия, как централизованный контроль, функционирование и конфигурирование. Более определенной целью настоящего изобретения является обеспечение интерфейсными модулями, имеющими архитектуруагентадаптера, и схемы сообщения, которые совместно улучшают трассировку и манипуляцию сообщениями в этих системах и способах. Другой целью настоящего изобретения является обеспечение в таких системах и способах улучшенных средств безопасности, включая такие аспекты, как аутентификация, авторизация, секретность, признание авторства и контроль. Еще одной целью настоящего изобретения является обеспечение систем и способов интеграции приложений для предприятия, которые включают средства восстановления после аварии, отказоустойчивого отката, воспроизведения сообщений и регистрации с двойным сайтом. Общая цель настоящего изобретения также состоит в том, чтобы способствовать быстрой и простой интеграции ведущих приложений ERP,специализированных/старых приложений, пакетных приложений и баз данных. Более опре 003744 10 деленной целью настоящего изобретения является уменьшение или существенное устранение потребности в дорогой разработке программных кодов, которые традиционно требуются для интеграции приложений. Другой целью настоящего изобретения является обеспечение системы EAI, имеющей распределенную архитектуру, которая способствует долгосрочной надежности, универсальности,гибкости и расширяемости, необходимым сегодняшним предприятиям. Еще одной целью настоящего изобретения является обеспечение системы EAI, которая увеличивает возвращение инвестиций на предприятии, позволяя предприятию усиливать существующие инвестиции ИТ, увеличивать его скорость выхода на рынок, осуществлять решения и реализовывать выгоды более быстро и уменьшать эксплуатационные затраты. Другой целью настоящего изобретения является обеспечение системы EAI, которая обеспечивает более быстрый доступ к информации о клиентах предприятия и о составлении счетов так, чтобы предприятие могло обслуживать своих клиентов более эффективно и качественно, создавая более сильные, более эффективные отношения. Дальнейшей целью настоящего изобретения является обеспечение системы EAI с пунктами интеграции "многие со многими", которая существенно устраняет проблемы обычных систем "общения концентраторов" и их риск "единственного уязвимого звена". Дальнейшей целью настоящего изобретения является обеспечение системы EAI, которая упрощает архитектуру информационной модели предприятия, обеспечивая центральный пункт интеграции фактически для всех приложений и платформ. Еще одной целью настоящего изобретения является обеспечение системы EAI,которая обеспечивает эффективное и экономичное совместное использование информации. Способы, устройства и элементы, описанные здесь, способствуют достижению вышеупомянутых и иных целей, преимуществ и новых особенностей согласно настоящему изобретению, решая проблемы, описанные выше. В соответствии с одним важным аспектом настоящего изобретения способ включает реализуемые с помощью компьютера средства для передачи сообщений между первым программным приложением и вторым программным приложением. Такой способ обычно включает этапы (а) получения первого сообщения, имеющего структуру данных первого программного приложения; (b) публикации сообщения для получения опубликованного сообщения от первого приложения; (с) конвертирования структуры данных опубликованного сообщения первого приложения в структуру данных второго приложения; (d) публикации этого сообщения в форме второго программного приложения; и (е) 11 получения опубликованного сообщения вторым программным приложением. Согласно другому важному аспекту настоящего изобретения устройство включает систему интеграции множества программных приложений. Такое устройство обычно включает средства маршрутизации сообщений в пределах системы; средства сохранения множества конфигураций преобразования данных и множества правил; средства для применения конфигураций преобразования данных к сообщениям; средства для применения правил к сообщениям; и средства для маршрутизации сообщений между средствами маршрутизации сообщений в пределах системы и программными приложениями и обладает выделенными средствами маршрутизации сообщений для соответствующих программных приложений. Альтернативно устройство настоящего изобретения включает систему интеграции множества программных приложений. Такая система обычно включает систему передачи сообщений предприятия, которая передает сообщения между программными приложениями; систему хранения баз данных, соединенную с системой передачи сообщений предприятия,которая хранит множество конфигураций преобразования данных и множество правил; интеграционную службу, также соединенную с системой передачи сообщений предприятия и включающую процессор преобразования данных, использующий конфигурации преобразования данных, хранящиеся в системе хранения баз данных, и процессор оценки правил, использующий правила, хранящиеся в системе хранения баз данных; и множество агент-адаптеров,соединенных с системой передачи сообщений предприятия, причем каждый агент-адаптер соединен с соответствующим программным приложением для передачи сообщений между системой передачи сообщений предприятия и соответствующим программным приложением. В соответствии еще с одним важным аспектом настоящего изобретения элемент включает компьютерно-читаемую среду, реализующую сегменты программного кода для интеграции множества программных приложений. Примеры такой компьютерно-читаемой среды включают (но не ограничены этим списком) магнитный жесткий диск; гибкий диск; оптический диск (например, CD-ROM, CD-R, CD-RW или любой диск, совместимый с известнымиDVD стандартами); магнитооптический диск; магнитную ленту; чип памяти; несущую волну,используемую для переноса компьютерночитаемых электронных данных, таких как используемые при отправке и получении электронной почты или при доступе к сети, включая Интернет, Интранет, Экстранет, виртуальные частные сети (virtual private networks - VPN),локальные сети (local area networks - LAN) и глобальные сети (wide area networks - WAN); 12 или любое другое запоминающее устройство,используемое для сохранения данных, доступных компьютеру. Примеры таких сегментов кода включают (но не ограничены этим списком) не только сегменты исходного текста и сегменты объектного кода, но также и компьютерные программы на любом языке, командах,объектах, программном обеспечении или любых средствах управления компьютером. Такие сегменты кода обычно включают (а) первый сегмент кода для передачи сообщений между программными приложениями; (b) второй сегмент кода для выполнения преобразования данных сообщений; (с) третий сегмент кода для применения правил к сообщениям; и (d) множество четвертых сегментов кода, каждый из который передает сообщения между соответствующими программными приложениями и первым сегментом кода. В соответствии еще c одним важным аспектом настоящего изобретения системы и способы ориентированы на компьютер. Примеры компьютера включают (но не ограничены этим списком) универсальный компьютер; мэйнфрейм; персональный компьютер; браузер сети; клиента электронной почты; сервер электронной почты; сетевой файловый сервер или сервер передачи сообщений; устройство Интернета; беспроводной телефон; пейджер; персональный цифровой ассистент (вспомогательное средство)(personal digital assistant - PDA); факсимильную машину; цифровой фотоаппарат или видеокамеру; цифровой магнитофон или видеомагнитофон; цифровое копировальное устройство или сканер; интерактивное телевидение; гибридную комбинацию любого из вышеупомянутых компьютерных средств и интерактивного телевидения; или любое другое устройство, включающее процессор, память, имеющее возможности ввода и вывода. Другие новые и одинаково важные аспекты настоящего изобретения станут более ясны из их детального описания, рассматриваемого вместе со следующими чертежами. Краткое описание чертежей Фиг. 1(а) изображает систему интеграции приложений для предприятия (EAI) (100) согласно настоящему изобретению, встроенную в окружение, включающее устаревшие программные приложения (40), пакетные программные приложения (20 и 30) и реляционные системы управления базами данных (50). Фиг. 1(b) иллюстрирует первый сценарий,в котором система, показанная на фиг. 1(а), используется для интеграции программного приложения планирования ресурсов предприятия(ERP) (20) со специализированными устаревшими приложениями (20). Фиг. 1(с) иллюстрирует второй сценарий, в котором система, показанная на фиг. 1(а), используется для интеграции двух или нескольких 13 различных пакетных программных приложенийERP (20). Фиг. 1(d) иллюстрирует третий сценарий, в котором система, показанная на фиг. 1(а), используется для интеграции одного или нескольких фронт-офис (front-office) (пользовательских) пакетных программных приложений (30) с одним или несколькими бэк-офис (back-office)(серверными) пакетными программными приложениями (20). Фиг. 1(е) иллюстрирует четвертый сценарий, в котором система, показанная на фиг. 1(а),используется для интеграции программных приложений информационных хранилищ, использующих две или несколько различных систем управления реляционными базами данных(relational database management systems RDBMS) (50) или систем управления многомерными базами данных. Фиг. 2 является блок-схемой системы EAI(100), показанной на фиг. 1(а)-1(е). Фиг. 3 изображает комплект разработки адаптера, используемый в системе, показанной на фиг. 2. Фиг. 4(а) иллюстрирует основную архитектуру агент-адаптера, которая используется в соответствии с первой реализацией настоящего изобретения. Фиг. 4(b) иллюстрирует расширяемую архитектуру агент-адаптера, которая используется в соответствии со второй реализацией настоящего изобретения. Фиг. 4(с) является блок-схемой, иллюстрирующей предпочтительную реализацию агентадаптера согласно изобретению, объединяющую оба подхода. Фиг. 5(а)-5(с) иллюстрируют структуру и интеграционные объекты, используемые в системе согласно настоящему изобретению. Фиг. 6 иллюстрирует пример структуры сообщения, используемого в системе согласно настоящему изобретению. Фиг. 7 показывает различные объекты,участвующие в информационных потоках, согласно настоящему изобретению. Фиг. 8 иллюстрирует типичный процесс преобразования, используемый в соответствии с настоящим изобретением. Фиг. 9 иллюстрирует процесс преобразования, показанный на фиг. 8. Фиг. 10(а) и 10(b) иллюстрируют преимущество использования концентраторов сообщений согласно настоящему изобретению. Фиг. 11(а)-11(с) изображают различные среды, в которых управляются узлы и службы согласно настоящему изобретению. Фиг. 12 является блок-схемой, иллюстрирующей системные службы согласно настоящему изобретению. Фиг. 13 является блок-схемой, иллюстрирующей этапы, необходимые для создания сообщения в соответствии с настоящим изобрете 003744 14 нием, без конвертирования необработанных данных. Фиг. 14 является блок-схемой, иллюстрирующей этапы, необходимые для создания сообщения в соответствии с настоящим изобретением, с конвертированием необработанных данных. Фиг. 15(а) иллюстрирует способ создания экземпляра сообщения из сообщения приложения в соответствии с первой реализацией настоящего изобретения. Фиг. 15(b) иллюстрирует способ создания экземпляра сообщения из сообщения приложения в соответствии со второй реализацией настоящего изобретения. Фиг. 15(с) иллюстрирует способ создания экземпляра сообщения из сообщения приложения в соответствии с третьей реализацией настоящего изобретения. Фиг. 15(d) иллюстрирует способ создания экземпляра сообщения из сообщения приложения в соответствии с четвертой реализацией настоящего изобретения. Фиг. 16 является первой диаграммой классов согласно настоящему изобретению. Фиг. 17 является второй диаграммой классов согласно настоящему изобретению. Детальное описание изобретения Вычислительная среда выполнения приложений на предприятии Изложение материала иллюстрируется чертежами, на которых отдельные части информационной экосистемы предприятия 10,упрощенная структура которой приведена на фиг. 1(а), обозначаются символами или цифровыми ссылками в тексте. Типичная информационная система 10 использует большое количество программных приложений, включая приложения для бэкофиса 20, предназначенные для планирования ресурсов предприятия (ERP (enterprise resourceplanning) системы), приложения для фронтофиса 30, предназначенные для управления продажами, сервисом, маркетингом (CRM (custom relationship management) системы), одно или более программных приложений, унаследованных от предыдущих решений по автоматизации предприятия 40, а также одно или более приложения для управления реляционными базами данных (RDBMS) 50. В течение последних нескольких десятилетий бизнес предприятия разрабатывали или приобретали много сложных,узкоспециализированных программных приложений. В более ранние времена это были теперь уже устаревшие приложения, которые, чаще всего, были разработаны для выполнения определенных функций (например, инвентаризации,финансов, учета, автоматизации товарооборота и учета людских ресурсов), но которые в настоящее время еще продолжают использоваться. В последнее время были сделаны существенные инвестиции в комплексные программные при 15 ложения от таких разработчиков программного обеспечения, как SAP, PeopleSoft, Oracle и Baan. Каждое из этих комплексных программных приложений обладает своими собственными мощными уникальными решениями. Таким образом, сложилось так, что типичное современное предприятие использует не менее двух различных комплексных программных приложений, работающих в одной вычислительной среде, что и составляет информационную экосистему предприятия. В такие комплексные программные приложения при разработке не были заложены инструменты обмена информацией друг с другом. В результате, предприятия были вынуждены интегрировать свои различные комплексные программные приложения путем дорогого специализированного программного кода. Проблемы интеграции подобных приложений для совместного использования часто занимают месяцы, если не годы напряженного труда. Поэтому системы интеграции приложений предприятия(EAI), такие как система 100, показанная на фиг. 1(а), в настоящее время являются насущной необходимостью. Однако, в отличие от систем EAI, известных из уровня техники, система 100 включает ориентированное на решения промежуточное программное обеспечение (solution-orientedmiddleware), которое облегчает его пользователям модификацию и полную интеграцию информации, постоянно находящейся в различных приложениях, через одну общую инфраструктуру. Это позволяет пользователю распределять информацию без заторов, прозрачно и быстро среди служащих, клиентов и поставщиков, достигая значительного повышения прибыли. Таким образом, система 100 обеспечивает надежную систему передачи сообщений с их промежуточным накоплением, средства брокеров сообщений и сильную архитектуру агентадаптеров для интеграции различных приложений предприятия. Система 100 имеет распределенную архитектуру и разработана с возможностью простого администрирования и управления. Она создана с целью удовлетворения всех требований информационной поддержки большой компании. Она разумно связывает различные приложения так, что они могут иметь доступ к информации и совместно ею пользоваться. Система 100 обладает промежуточным программным обеспечением, которое само адаптируется к приложениям, вместо адаптации приложений к нему. Система 100 решает большинство проблем системы EAI, позволяя ее пользователям связывать ERP приложения 20, комплексные CRM приложения 30, специализированные и устаревшие приложения 40 и базы данных 50 предприятия с минимальной необходимостью написания новых программ. При полной интеграции предприятие может быстро синхронизировать 16 бизнес в глобальном масштабе, а также работу отдельных подразделений и быстро и адекватно реагировать на требования рынка. При быстром доступе к информации о клиентах и генерации счетов компания может обслуживать клиентов более эффективно и качественно, обеспечивая их удержание и лояльность. Система 100 представляет собой бизнес-ориентированное решение интеграции информационных потоков предприятия, осуществляющее информационную поддержку для бизнес-аналитиков. Аналитик определяет проблему в понятных ему терминах бизнеса, а продукт решает ее технически. Например, как показано на фиг. 1(b), общий сценарий интеграции приложений, предназначенных для планирования ресурсов предприятия (ERP) (20), со специализированными устаревшими приложениями требует, чтобы компания разработала сложные программы обработки данных от устаревших систем, чтобы они соответствовали стандартам ERP-приложений, как правило, это не простая задача. Многие корпорации предпочитают использовать стандартные пакеты программ для различных бизнеспроцессов, например программы складского учета или обработки заказов клиентов. Но комплексные приложения редко используются для вертикальных процессов. Для этих целей система 100 идеальна. Она обеспечивает объектноориентированные интерфейсы для систем ERP 22, 24, 26, 28, а также обладает технологией созданий оболочек для подключения устаревших приложений 44, 48 к системе. Расширение глобальной системы поставок товаров также требует, чтобы промежуточное программное обеспечение соединило две или более различных систем ERP 22, 24, 26, 28. Зная реальную ситуацию, можно легко понять, как важно организовать ресурсное планирование между отдельными подразделениями большой компании (фиг. 1(с. Система 100, таким образом, играет ключевую роль, обеспечивая транзакции междуERP-приложениями, когда бизнес-события в одной системе (например, SAP системе 22) вызывают соответствующие изменения в другой системе (например, Вааn системе 28) без необходимости изучать подробности технологии каждой из систем. Интеграция фронт-офиса (front-office) с бэк-офисом (back-office) корпорации является важной функцией, которая позволяет приложениям фронт-офиса, которые взаимодействуют с клиентом, сотрудничать с серверными производственными приложениями. Например, жизненно важно, чтобы приложение, обрабатывающее заказы клиентов, взаимодействовалo сERP-приложением для складов. Система 100, таким образом, способствует интеграции лучше всего зарекомендовавших себя приложений для фронт-офиса и бэк-офиса друг с другом. 17 В схеме организации информационного хранилища, как показано на фиг. 1(е), данные от различных систем должны перемещаться к центральному информационному хранилищу или в архив. Перемещение информации в реальном масштабе времени от нескольких ERPприложений (не показанных на фиг. 1(е к центральной реляционной базе данных или многомерным базам данных, содержащим, в свою очередь, множество различных баз данных 53,56, 59, типично для этой проблемы. Однако, используя ресурсы системы 100,разработчики могут создавать новые приложения для конвертирования данных (как это сделать, будет более подробно описано ниже), что позволяет эффективно решать проблему объединения данных в реальном масштабе времени или других процессов. Таким образом, данные конвертируются в форму, доступную для восприятия и использования. Определения Используемые ниже термины должны восприниматься в соответствии с их значением и смыслом так, как они известны из существующего уровня техники. Термины, известные из существующего уровня техники, которые заявитель переопределил ниже, следует воспринимать в соответствии с той формулировкой, которая предложена заявителем."Средство доступа" является функцией,указанной в определениях сообщений, которые система 100 использует для доступа к данным. Средства доступа идентифицируют начало и конец полей данных приложения и системных элементов сообщений и удаляют или вставляют маркеры."Реализации адаптера" являются программными кодами, разработанными для определенного приложения, которые могут извлекать данные и производить на их основе системные сообщения: принимать системные сообщения и обновлять данные; или извлекать данные в ответ на запросы. Когда пользователь создает адаптер для использования в интеграционном потоке, то он формирует его как реализацию адаптера. Системные реализации адаптера обеспечивают основную обработку особых ситуаций и могут обрабатывать любое определение сообщения. Пользователь создает специализированные реализации адаптера, используяADK, как определено и более подробно описано ниже."Адаптеры" являются объектами интеграционного потока, которые взаимодействуют с приложениями предприятия для извлечения или вставки данных, обновления или удаления данных."Административная консоль" является графическим интерфейсом пользователя (GUI),через который администратор системы конфи 003744"Службы агентов" обеспечивают системные службы для адаптеров. Служба агентов требуется на каждом хосте, на котором работает адаптер."Classpath" является переменной окружения, которая говорит виртуальной машине Java,где найти библиотеки классов, включая определяемые пользователем библиотеки классов."Клиенты" являются процессами, которые дистанционно получают доступ к ресурсам компьютера сервера, таким как вычислительная мощность и память большой емкости. Типичными системными клиентами являются автоматизированное рабочее место (АРМ) с интеграционными инструментальными средствами 120 и административная консоль 160 (фиг. 2)."Соединение" является объектом, который определяет параметры запуска или соединения для адаптеров. Например, RDBMS соединение определяет JDBC драйвер, URL базы данных,имя пользователя и пароль."Конвертирование" данных является процессом, в котором конвертеры, указанные в определениях сообщений, конвертируют исходные типы данных приложения к типам данных Java,поддерживаемых системой 100, и наоборот."Конвертер" является функцией, указанной в определениях сообщений, которую система 100 использует для конвертирования данных. Таким образом, конвертеры конвертируют исходные типы данных в типы данных Java, поддерживаемых системой 100, и наоборот."Специализированные реализации адаптера" являются программными кодами, разработанным и для определенного приложения, которые могут либо извлекать данные и производить системные сообщения; получать системные сообщения и обновлять данные, либо извлекать данные в ответ на запросы. Специализированные реализации адаптера, созданные с использованием автоматизированного рабочего места(АРМ) ADK 130, могут соединяться с приложениями, которые система 100 в настоящее время не поддерживает."Объект определения" является объектом интеграционного потока, который обеспечивает команды для процесса, который должна осуществить система."Ограничители" являются лексемами или маркерами, которые отделяют поля данных в данных приложений предприятия."Длительная подписка" является свойством концентраторов системных сообщений, которое гарантирует, что объекты назначения концентратора получат все сообщения, предназначенные для них. Если объект назначения становится неактивным, система помнит те сообщения, которые получил объект назначения. Когда объект назначения затем становится ак 19 тивным, система доставляет сообщения, которые объект назначения еще не получил."Приложения предприятия" являются приложениями, из которых адаптеры извлекают данные или для которых адаптеры распространяют данные (например, SAP R/3 или MQSeries).(EMS)" - согласно этому изобретению осуществляется обмен информацией с использованием службы передачи сообщений Java (JMS). Это позволяет системе 100 использовать режимы множественной передачи сообщений, поддерживать концентраторы сообщений и обеспечивать сохранность сообщений. Приложения "планирования ресурсов предприятия" (ERP) обеспечивают решение под ключ (например, управление хранилищем,управление людскими ресурсами и управление материалами) для общих проблем бизнеса. Примерами продуктов ERP являются SAP R/3,PeopleSoft и Baan."EntireXBroker (ETB)" является согласно этому изобретению межплатформным, ориентированным на сообщения промежуточным программным обеспечением, которое соединяет приложения и компоненты универсальной ЭВМ, Windows NT и UNIX, Интернет и Интранет клиентов, ActiveX и Java рабочих станций."Определения фильтрации" являются объектами определений, которые определяют критерии для удаления сообщений из интеграционных потоков."Хост функций" является вычислительной платформой, такой как сервер Windows NT, рабочая станция или OS/390 универсальная ЭВМ."Концентраторы" являются объектами интеграционного потока, которые получают сообщения от объектов источников и удерживают сообщения, пока система 100 доставляет их определенным объектам назначения. Концентраторы позволяют адаптерам и преобразователям обмениваться сообщениями асинхронно. Они также полезны для концентрации потоков сообщений: многочисленные объекты, которые производят один и тот же тип сообщений, могут все посылать эти сообщения одному концентратору сообщений, который упрощает соединения объектов."IDoc экстрактор" читает простые файлы,произведенные приложением SAP R/3 транзакцией WE63, для создания конфигураций реализации и определений сообщений и сохраняет их в архивной службе системы."Параметры реализации" являются временными параметрами выполнения для адаптеров (например, интервал опроса)."Интеграционный поток" представляет ряд связанных системных объектов, которые перемещают данные от одного или нескольких приложений предприятия к другим приложениям предприятия."Интеграционные объекты" являются объектами интеграционного потока, которые посылают сообщения, получают сообщения или делают и то, и другое. См. например, адаптеры,концентраторы и преобразователи."Интеграционные инструментальные средства" являются графическим интерфейсом пользователя (GUI), через который пользователь разрабатывает интеграционные потоки."Промежуточные документы (IDocs)" являются SAP R/3 форматом данных, используемым программным приложением R/3 для обмена данными с другими версиями R/3 и с другими приложениями."Единичный элемент сообщения" является элементом сообщения, который содержит данные. Единичные элементы являются элементами сообщений самого низкого уровня в иерархии определения сообщения. Они не могут содержать другие элементы сообщений."Комплект разработки Java (Java Development Kit - JDK)" является средой программирования для написания приложений на языке программирования Java.Java (Java Naming and Directory Interface - JNDI)" является набором таких API, которые помогают связываться со службами множественных наименований и каталогов.Environment - JRE)" является подмножеством комплекта разработки Java, используемого для перераспределения среды выполнения, состоящей из виртуальной машины Java, классов ядраmachine - JVM)" является частью среды выполнения Java, ответственной за интерпретацию байт-кодов."Маркеры связи" являются лексемами или ограничителями, которые отделяют поля данных приложений предприятия."Категория определения сообщения" является логической группой для определений сообщений."Определения сообщений" являются объектами, которые идентифицируются, чтобы система данных 100 могла их извлечь из или распространить к приложению предприятия. Определения сообщений также определяют, как система 100 должна создавать системные сообщения из сообщений приложения предприятия или создавать сообщения приложения предприятия из системных сообщений."Элемент сообщения" является объектом данных, который представляет собой структурный элемент сообщения. Элементы сообщений размещаются в иерархической структуре и могут быть секциями, таблицами или единичными элементами."Ориентированное на сообщения промежуточное программное обеспечение (MessageOriented Middleware - MOM)" является программным обеспечением, которое использует сообщения для связи приложений на единой или различных платформах. Протоколы связи скрыты от приложений. Примерами MOM являются"Сохранность сообщения" относится к сохранению сообщений на восстанавливаемых носителях. Система записывает каждое сообщение, которое она доставляет от одного интеграционного объекта к другому, в устойчивой памяти в местоположении, которое указывает пользователь. Если происходит системный отказ во время передачи сообщения, система 100 может восстановить сообщение из памяти при восстановлении системы 100 и доставить сообщение объектам назначения."Схема сообщения" является той частью определений сообщений, которая указывает, как структурировать сообщение. Схемы сообщений могут включать секцию, таблицу и единичные элементы сообщений, размещаемые в иерархической структуре."Службы контроля" хранят системные данные во время выполнения, включая системные файлы регистрации и статистическую информацию.(или виртуальной машиной Java), который поддерживает один или большее количество системных служб и служб приложений."Хосты узла" являются программами, которые позволяют пользователю конфигурировать и выполнять узлы на машине. Пользователь должен инсталлировать хост узла на каждой машине, которая будет хостом узла, в отличие от менеджера узлов."Менеджер узлов" является интерфейсом,через который управляются узлы. Интерфейс позволяет пользователю конфигурировать, запускать, приостанавливать или останавливать службу. Менеджеры узлов также запускают и останавливают узлы. Менеджер узлов поддерживает состояние всех служб, которые распределены по узлам. Кроме того, менеджер узлов поддерживает информацию состояния (например, текущее состояние или уровень активности) узла или службы."Двухточечная передача сообщений" является стилем передачи сообщений для концентраторов, в которых система доставляет каждое сообщение, которое достигает концентратора только к единственному объекту назначения 22 концентратора (то есть к первому доступному объекту назначения)."Первичное входное сообщение" является основными входными данными для системного процесса преобразования, указанного в определениях преобразования. Система берет входные данные, преобразует их и создает выходные данные, необходимые для приложений назначения."Передача сообщений публикация/подписка" является стилем передачи сообщений для концентраторов, в котором система доставляет каждое сообщение, которое достигает концентратора, ко всем объектам назначения концентратора."Средство ответа" является системным объектом, таким как адаптер ответа, который обеспечивает данные, когда преобразователи запрашивают их в ходе процесса преобразования данных."Адаптеры ответа" являются интеграционными объектами, которые отвечают на запросы данных от других интеграционных объектов,извлекая данные из приложений и посылая их запрашивающим объектам. Запрашивающие объекты посылают системные сообщения, содержащие данные в ключевых элементах сообщений, а адаптеры ответа вставляют данные в связанные элементы сообщений и посылают системные сообщения обратно."Архивная служба" сопряжена через "собственный интерфейс каталогов Java" и сохраняет конфигурации для всех сконфигурированных служб и объектов интеграционного потока."Службы маршрутизации" позволяют системе направлять сообщения через систему на основе содержания сообщения, включая фильтрацию содержания сообщения согласно критериям, которые определяет пользователь. Служба маршрутизации поддерживает фильтры."Системное сообщение" является сообщением в платформенно-независимом формате,которое система использует для перемещения данных от приложения к приложению."Секционные элементы сообщений" являются неповторяющимися группами элементов сообщений, которые не содержат фактические данные. Они содержат другие элементы сообщений, которые содержат данные (то есть они содержат единичные элементы). Секции могут содержать любую комбинацию типов элементов сообщений."Служба" является процессом, который обеспечивает функциональные возможности продукта. Система составлена из системных служб, служб передачи сообщений, интеграционных служб и служб агентов."Адаптеры источника" являются интеграционными объектами, которые извлекают данные из приложений предприятия, создают системные сообщения из данных и посылают со 23 общения другим системным интеграционным объектам."Объекты источника" являются объектами интеграционного потока, которые обеспечивают сообщения для других объектов. См., например,адаптеры источника, преобразователи и концентраторы."Поддерживающие входные сообщения" являются необязательными входными данными для системных процессов преобразования, как указано в определениях преобразования. Процессы преобразования используют данные поддерживающих входных сообщений для дополнения данных первичных входных сообщений. Система извлекает входные данные из поддерживающих сообщений, преобразует их и создает выходные данные, необходимые приложениям назначения."Табличный элемент сообщения" является группой секционных элементов сообщений,называемых строками, которые могут повторяться любое число раз. Названия табличных элементов не содержат фактические данные, а лишь обозначают группы элементов сообщений,которые содержат данные (то есть они содержат единичные элементы). Таблицы могут содержать любую комбинацию типов элементов сообщения."Адаптеры назначения" являются интеграционными объектами, которые получают системные сообщения от других интеграционных объектов, создают данные приложения из системных сообщений и распространяют данные к приложениям назначения."Интеграционный объект назначения" является объектом интеграционного потока, который получает сообщения от других объектов. См., например, адаптеры назначения, преобразователи и концентраторы."Контроль обработки транзакций (Transaction Processing Monitor - TPM)" является программной системой, разработанной для оптимизации использования вычислительных ресурсов,таких как память и приложения, для многих пользователей."Преобразование данных" является процессом, в котором преобразователи изменяют данные, принятые от одного или нескольких приложений предприятия, в данные, необходимые другим приложениям предприятия."Службы преобразования" позволяют системе преобразовывать сообщения, включая разбиение сообщений, объединение сообщений и управление данными сообщения. Службы преобразования поддерживают преобразователи."Этап преобразования" является командой,которая является частью процесса преобразования. Каждый этап или читает входные данные сообщения, преобразует и отображает входные данные сообщения в выходных определениях сообщений, или записывает преобразованные данные в выходные сообщения."Определения преобразования" являются объектами, которые определяют, как система должна преобразовывать системные сообщения,извлеченные из одного или нескольких приложений предприятия, в системные сообщения,необходимые другим приложениям предприятия."Преобразователь" является интеграционным объектом, который осуществляет определения преобразования. Преобразователи собирают входные сообщения от интеграционных объектов источников, преобразуют содержание и формат данных сообщения и производят и посылают выходные сообщения интеграционным объектам назначения.interface services - UIS)" обеспечивают средства интерфейса пользователя, необходимые для выполнения клиентских компонентов (т.е. автоматизированное рабочее место (АРМ) с интеграционными инструментальными средствами 120 и административная консоль 160). На фиг. 2 приведена система 100, которая в общем виде включает в себя множество компонентов 110, предназначенных для проектирования самой системы 110, и множество компонентов 150, предназначенных для управления системой 110. Модуль для проектирования 110, в свою очередь, обычно имеет автоматизированное рабочее место 120 с инсталлированными средствами для интеграции приложений, автоматизированное рабочее место 130 с комплектом средств для разработки адаптеров (ADK) и архивную службу 140. Модуль управления 150,в свою очередь, включает административную консоль 160, интеграционный сервер 170 с процессором обработки сообщений 180, модуль службы узлов 190, набор интеллектуальных агент-адаптеров 200. Автоматизированное рабочее место 120 обычно имеет инсталлированные инструменты графического моделирования и конфигурации для разработки проекта интеграции приложения. Они используются для разработки служб определения событий, сообщений, которые связаны с этими событиями, интеграционных потоков и бизнес-правил, связанных с этими интеграционными потоками, а также идентификации агентов, которые создают и подписываются на определенные события. Кроме того, автоматизированное рабочее место 120 обеспечивает диагностику целостности и тестирование интеграционных потоков.ADK 130 используется для конфигурации стандартных и разработки специализированных интеллектуальных агент-адаптеров 200. ADK 130, структурная схема которого приведена на фиг. 3, обычно представляет собой объектноориентированные средства разработки, включающие в себя библиотеки классов 132, мастера создания адаптеров 134 и шаблоны 136. 25 С помощью ADK 130 разработчик может создавать объекты, которые могут быть получены с помощью обычных (стандартных) средств разработки. Система 100 имеет множество стандартных интеллектуальных агент-адаптеров 200, которые охватывают широкий спектр приложений и ресурсов, но может оказаться, что для определенного приложения нет стандартного интеллектуального агент-адаптера 200. В этом случае разработка такого интеллектуального агент-адаптера 200 осуществляется разработчиками на ADK 130, которые наиболее знакомы с имеющимися интерфейсами, используемыми данным приложением. Служба архива 140 обычно включает реляционную базу данных, которая содержит описание всех технических характеристик системы 100, метаданные, правила служб брокеров сообщений и интерфейс доступа к этой реляционной базе данных. Административная консоль 160 используется для конфигурации и управления функционированием системы 100 и обычно представляет собой компьютер с графическим интерфейсом,дружественным для пользователя. Она служит пунктом управления для осуществления конфигурирования, обслуживания, контроля и диагностики системы 100. Административная консоль 160 управляет каждым из индивидуальных компонентов системы 100. С ее помощью пользователь может запускать и останавливать приложения, а также распределять программное обеспечение. Интеграционный сервер 170 осуществляет интеллектуальную передачу сообщений, переключая и запуская интеграционные потоки для обработки событий. Он задает статические и динамические контекстуально зависимые правила, которые оценивают, изменяют и направляют потоки данных, содержащиеся в событиях. Как было отмечено выше, интеграционный сервер 170 имеет встроенный процессор обработки сообщений предприятия 180, который имеет подсистему распределения сообщений, управляющую всеми данными событий. Он является,с одной стороны, ключевым компонентом системы 100. С другой стороны, он в значительной степени прозрачен для любого пользователя системы 100 и обычно работает в фоновом режиме. Он поддерживает абсолютно устойчивую систему доставки сообщений, работающую по принципу "однажды и только однажды", а также, загруженный в память, режим обработки сообщений большого объема, имеющих низкий приоритет. Служба узлов 190 управляет восстановлением при запуске/повторном запуске сообщений, обработкой особых ситуаций и задает динамическую конфигурацию системы 100. Она обеспечивает автоматическую загрузку системы и имеет средства удаленного управления всеми клиентами и серверами, которые находятся в 26 системе. Кроме того, она способна к дистанционной установке и модификации компонентов. Как отмечалось выше, множество интеллектуальных агент-адаптеров 200 включает не только те стандартные интеллектуальные агентадаптеры 200, которые поставляются с системой 100, но также и специализированные интеллектуальные агент-адаптеры 200, которые разработаны с помощью автоматизированного рабочего места ADK 130. Каждый такой интеллектуальный агент-адаптер 200, независимо от его типа,представляет собой загрузочный интерфейсный модуль, соединяющий определенные ресурсы приложения 300, которые предназначены для работы с внешними модулями, с системой 100. На фиг. 4(а) и 4(b) приведены интеллектуальные агенты-адаптеры 200 в соответствии с одним из аспектов настоящего изобретения,которые объединяют функциональные возможности автономных объектов с технологией адаптеров. Агент 210 действует как независимый программный процесс, который является главным по отношению к одному или нескольким адаптерам 220 (фиг. 4(а или 222 и 224 (фиг. 4(b. Он включает (инкапсулирует) такие сложные функциональные возможности, как кэширование данных с промежуточным хранением,фильтрацию, объединение ресурсов и планирование. Главным преимуществом архитектуры агент-адаптера является ее возможность учитывать сложную логику бизнеса для обработки транзакций, которая характеризуют состояние транзакции или предназначена для согласования с ресурсами приложения 300. Этот процесс можно считать функционированием в диалоговом режиме, который является особенно критичным при интеграции ресурсов приложения 300 транзакционного характера. Чаще всего,элементы данных, которые могут требоваться брокерам сообщений от таких ресурсов приложения 300, находятся среди тех данных, которые являются основой формирования транзакций. Эти глубоко вложенные элементы данных могут быть получены только посредством вступления в диалог с тем ресурсом приложения 300, которое формирует транзакцию. Иначе"примитивные" адаптеры, которые использовались в прошлом, будут неадекватно использовать сведения, которые являются результатом сложного процесса в приложении 300, происходящего при формировании транзакции. На фиг. 4(а) приведен типичный интеллектуальный агент-адаптер 200 согласно настоящему изобретению, состоящий из агента 210 и адаптера 220. С одной стороны, при этой архитектуре агент 210 должен обрабатывать определенное событие и модель передачи сообщения, которое связано с этим событием, системе 100. А адаптер 220, с другой стороны, использует собст 27 венный программный интерфейс (applicationprogramming interface - API) 510 конкретного ресурса приложения 300 или другой стандартный программный интерфейс, который разработан для работы с приложением 300. Вместе агент 210 и адаптер 220 устраняют различия в протоколах интерфейсов и структурах данных для формирования нормализованного отображения бизнес-события в информационной среде с целью его опубликования и использования. В отличие от предыдущих подходов к EAI,вышеупомянутая архитектура агент-адаптера допускает расширение. Она не только способствует возможности бесшовной адаптации изменений к существующим интерфейсам приложений (API), но это также дает возможность использования существующих API со старыми системами. На фиг 4(b) приведена более подробно эта расширяемая архитектура агентадаптера, в которой агент 210 включает в себя(инкапсулирует), первый адаптер А' 222 и второй адаптер А" 224. Адаптер А' 222, например, соответствует ресурсу приложения 300, имея основной интерфейс API А'. С другой стороны, адаптер А" 224 соответствует тому же самому ресурсу приложения 300, но с другим набором интерфейсаAPI А". Пользователи такой расширенной архитектуры агент-адаптера могут, таким образом,одновременно адаптироваться к обоим интерфейсам А' и А". Например, основной интерфейсAPI A' может соответствовать ресурсу, который обеспечивает информационную поддержку производства, в то время как новый интерфейс API А" может соответствовать новой версии определенного ресурса приложения 300, который обеспечивают информационную поддержку подготовки производства. Новый интерфейсAPI А" может, таким образом, быть протестирован "живьем" в рамках системы 100, в то время как основной интерфейс API А' будет использоваться для поддержки ранее протестированных и проверенных функциональных возможностей. Таким образом, эта расширяемая архитектура агент-адаптера позволяет обеспечить беспроблемное согласование изменения ресурса приложения 300 в интеграционной среде. На фиг. 4(с) приведена более детальная схема агент-адаптера 200, которая наиболее полно соответствует формуле данного изобретения. Подобно агент-адаптерам, приведенным на фиг. 4(а) и 4(b), агент-адаптер 200, показанный на фиг. 4(с), используется для подключения собственного интерфейса API 510 приложения(оно на рисунке не приведено) к системе 100. Агент-адаптер 200 согласно этой схеме состоит из трех адаптеров 222, 224 и 226. Адаптер 222 принадлежит к множеству адаптеров источника, адаптер 224 принадлежит к множеству адаптеров назначения, и адаптер 226 принадле 003744 28 жит к множеству адаптеров ответа, более подробно функциональное назначение этих адаптеров будет описано ниже. Следовательно, специалисты могут оценить, что агент-адаптер 200 согласно этой реализации настоящего изобретения может быть неограниченно усилен любым числом специальных адаптеров, которые могут быть включены (инкапсулированы) в агент 210. Например, адаптер запроса 228 (не показан на фиг. 4(с) и будет более подробно описан ниже),может использоваться в дополнение или взамен адаптеров 222, 224 или 226, приведенных на фиг. 4(с). Кроме того, согласно другому важному аспекту настоящего изобретения агент 210 включает множество объектов 230-240, используемых для расширения возможностей агентадаптера 200. Например, объект 230 в данном случае включает в себя функции объекта преобразования, который способствует выполнению функций централизации системы 100 локально внутри самого агент-адаптера 200. Объект 231 аналогично включает в себя функции обработки ошибок, объект 232 - функции управления соединениями, а объект 234 - функции управления правилами. Дальнейшая расширяемость агентадаптера 200 ограничена только числом дополнительных агентов 235-240, которые могут быть расположены в агенте 210. Описанная выше структурная схема является важным аспектом настоящего изобретения,так как в ней сформулирован метод децентрализации обработки сообщений системы 100. Следовательно, обеспечена распределенная интеграция приложений предприятия, так как агентадаптер 200 согласно этой реализации настоящего изобретения может быть связан с любым из узлов системы 100. Способ, которым система 100 разделяет данные среди приложений предприятия, определяется интеграционными потоками, что более подробно описано ниже. Типичные интеграционные потоки используют одно или несколько системных сообщений. Каждое из системных сообщений обычно состоит из соединения, в результате которого происходит перемещение данных от одного программного приложения к другому. Интеграционные потоки, в свою очередь, состоят из множества объектов и связей между этими объектами. Каждый из объектов выполняет определенную задачу, относящуюся к системным сообщениям, которые переносят данные от одного приложения предприятия к другому приложения предприятия. Например, на фиг. 5(а)-5(с) объект в интеграционном потоке 540 включает или объект определения 510, или интеграционный объект 530. Имеются три основных типа объектов определения 510, которые могут использоваться согласно настоящему изобретению: (1) определение сообщения 512; (2) определение преобразования 514; и (3) определение фильтра 516. Объекты определений 510 могут использоваться 29 неоднократно в любом интеграционном потоке 540. Например, одно и то же определение сообщения 512 должно быть передано всем объектам 510, 530, которые обработают системные сообщения, произведенные с использованием данных, полученных от объекта 512. Кроме того, одно и то же определение фильтра 516 может использоваться в многочисленных секциях интеграционного потока 540. Объект 512 определения сообщения идентифицирует данные, которые система 100 должна извлечь из или направить для использования приложениями предприятия 541, 549. Он также определяет, не только как система 100 будет создавать системные сообщения из данных, полученных от приложений предприятия, но также и как она будет создавать данные для приложений предприятия из системных сообщений. Объекты 514 определения преобразования определяют, как система 100 будет преобразовывать системные сообщения, извлеченные из одного или нескольких приложений предприятия, в системные сообщения, необходимые другим приложениям предприятия. Объект 516 определения фильтра задает критерии удаления нежелательных системных сообщений из интеграционных потоков, которые будет использовать система 100. В интеграционном потоке, который преобразует новые данные клиента в счета-фактуры, например, мог бы быть полезен тот фильтр объекта 516, который удалял бы системные сообщениях о клиентах, которые уже оплатили. Интеграционные объекты 530 трех основных типов фактически посылают или получают системные сообщения. К трем основным типам интеграционных объектов 530 относятся (1) адаптер 220; (2) концентратор сообщений 518; и(3) преобразователь 520. Кроме того, как кратко отмечено выше, имеются четыре основных типа адаптеров 220: (а) адаптеры источника 222; (b) адаптеры назначения 224; (с) адаптеры ответа 226; и (d) адаптеры запроса 228. Адаптер источника 222 извлекает данные из исходного приложения предприятия, создает системные сообщения из этих данных и посылает эти системные сообщения другим интеграционным объектам 530 (например, концентратору сообщения 518). Адаптер назначения получает системные сообщения от других интеграционных объектов 530 (например, от преобразователя 520 через фильтр 516), создает данные для своего приложения из этих системных сообщений и направляет эти данные приложению предприятия, с которым он работает. Адаптер ответа 226 отвечает на запросы данных от некоторых других интеграционных объектов 530,извлекая данные из своего приложения, а затем посылая их запрашивающему объекту 530. Обычно концентраторы сообщений 518 используются для получения системных сообщений от одного или нескольких интеграцион 003744 30 ных объектов источников 530 и удержания этих системных сообщений до тех пор, пока система 100 не сможет доставить их одному или нескольким интеграционным объектам назначения 530. Преобразователи 520 обычно осуществляют выбор нужного преобразования с помощью процедуры, состоящей из трех этапов. Сначала они аккумулируют системные сообщения от интеграционных объектов источников 530 (например, концентраторов сообщений 518). После этапа аккумуляции они преобразуют содержание и форматируют данные, содержащиеся в таких системных сообщениях. Наконец, они производят и посылают выходные системные сообщения интеграционным объектам назначения 530 (например, адаптеру назначения 224). Объекты определения сообщений 512 являются первичными объектами, вокруг которых сформирован интеграционный поток 540 согласно настоящему изобретению. Когда пользователь создает интеграционный поток, определение сообщения присвоено каждому объекту 510, 530 в этом потоке. Определение сообщения 512 не только идентифицирует тип системного сообщения, которое должен обработать объект 510, 530, но оно также определяет иерархическую структуру или схему этого системного сообщения. Например, определение сообщения 512 должно быть направлено каждому адаптеру источника 222 в интеграционном потоке пользователя 540. Каждый адаптер источника 222 знает,какое сообщение он должен произвести, основываясь на определении сообщения 512, которое пользователь направил ему. Адаптеры 220,концентраторы 518 и фильтры 516 обрабатывают только одно определение сообщения 512. Объекты определения преобразования 514 и преобразователи 520, с другой стороны, способны к обработке множества определений сообщений 512, как входящих, так и исходящих. Некоторые приложения могут создавать типы данных Java, которые поддерживает система 100. В этих случаях адаптер источника 222 может извлекать типы данных, указанные в определении сообщения 512, и сохранять их непосредственно в системном сообщении. Аналогично адаптер назначения 224 может извлекать типы данных из системного сообщения и вставлять их непосредственно в приложение (например, приложение предприятия назначения 549). Другие приложения используют строго определенный формат сообщения для описания размещения их собственных данных. В этих случаях определение сообщения 512 для адаптера источника 222 должно включать инструкции для создания типов данных Java из данных приложения. Точно так же определение сообщения 512 для адаптера назначения 224 должно включать инструкцию для создания данных для приложения из системных объектов Java. 31 Специальный тип определения сообщения 512 используется интеграционными объектами 530 для запроса данных от других системных объектов 510, 530. Например, определения сообщений 512 могут также указывать критерии проверки правильности сообщения. Система 100 использует эти критерии для определения,содержат ли системные сообщения, произведенные адаптерами 220 и преобразователями 520, достоверные данные (например, где пользователь включил определение сообщения 512,определяющее сообщение, которое содержит информацию о зарплате служащего). Пользователь соответственно может защищать систему 100 от ввода неточных данных о зарплате. Если определение сообщения 512 содержит единичный элемент "Зарплата", например, пользователь мог бы тогда указать следующий критерий проверки правильности ввода единичного элемента, а именно, что это сообщение действительно только тогда, когда числовое значение"Зарплата" является положительным числом. Пользователь может организовывать определения сообщений 512 в виде логических групп,связанных друг с другом и называемых категориями сообщений. Предположим, например, что пользователь производит интеграцию трех приложений в информационную систему предприятия через систему 100. Пользователь мог бы группировать сообщения в своем проекте в трех категориях сообщений, по одной для каждого приложения. На фиг. 6 приведена структурная схема конкретного сообщения 600, которая определяется (устанавливается) объектом определения сообщений 512. Сообщение состоит из данных,которые расположены внутри сообщения в соответствии с определенной иерархией. Обычно схема сообщения 600 включает одну или несколько секций 620, одну или несколько таблиц 640 и один или несколько единичных элементов 660. Секция 620 или таблица 640 должна находиться вверху иерархии сообщения 600. Секция 620 является группой неповторяющихся элементов сообщения. Элементы,которые указывают названия секций, сами данных не содержат, а только задают названия. В секции содержатся элементы сообщений, которые содержат данные (то есть они содержат единичные элементы 660). Секции 620 могут содержать любую комбинацию типов элементов сообщения. Таблица 640 является группой секционных элементов, называемых строками, которые могут повторяться любое число раз. Элементы,которые задают названия таблиц, также не содержат фактические данные. Они лишь указывают на элементы сообщений, которые содержат данные (то есть они содержат единичные элементы). Таблицы 640 могут содержать любую комбинацию типов элементов сообщения. 32 Единичный элемент 660 является элементом сообщения, который содержит данные. Единичные элементы 660 являются элементами сообщений самого низкого уровня в структурной иерархии сообщения. Они не могут состоять из других элементов сообщения. Каждый объект определения сообщений 512 может содержать критерии для проверки достоверности сообщений, основанные на определении сообщения. То есть, когда пользователь определяет структуру сообщения, он может указать критерии, которым должны удовлетворять данные в индивидуальных элементах сообщений с тем, чтобы получить более высокую достоверность данных, используемых в системе 100. Пользователь может указать критерии проверки правильности для всех уровней в структуре сообщения. То есть пользователь может указать как критерии для единичных элементов, так и для названий секций или таблиц. Все элементы сообщения или удовлетворяют критериям проверки правильности и сообщение остается в потоке, или не удовлетворяют и сообщение целиком отбрасывается. Если даже одна строка таблицы не удовлетворяет указанным критериям, то все сообщение не удовлетворяет. Система 100 проверяет правильность каждого сообщения, произведенного адаптером 220 или преобразователем 520, используя критерии проверки правильности для соответствующего определения сообщения. Адаптеры 220 соединяются с приложениями предприятия для извлечения или распространения данных. Каждый адаптер 220 производит, получает или отвечает на сообщения,используя объект определения сообщений 512,который пользователь ему присвоил. Система 100 обеспечивает стандартными адаптерами 220 приложения, которые интегрированы в информационную среду предприятия. Каждый стандартный адаптер 220, как отмечено выше, является адаптером источника 222, адаптером назначения 224, адаптером ответа 226 или адаптером запроса 228 и разработан для службы агентов определенного типа. Например, для программного обеспечения EntireX Broker система предлагает "адаптер источника стандарта ЕТВ" и "адаптер назначения стандарта ЕТВ". Стандартные адаптеры составляют основу системы 100. Они обеспечивают основную обработку ошибок и могут выполнять любое определение сообщения. Если стандартный адаптер 220 не включает все инструкции, которые необходимы пользователю для взаимодействия с приложением (например, пользователь хочет указать более детальную обработку ошибок), пользователь может создать специализированный адаптер 220, используя автоматизированное рабочее место ADK 130. Пользователь может также использовать ADK 130 для создания специализированных адаптеров 220 для приложений, кото 33 рые в данный момент не поддерживаются системой 100. Аналогично пользователь может использовать ADK 130 для создания специализированных адаптеров 220, которые соединяются с любым приложением посредством прикладного программного интерфейса (API) JAVA. Для использования стандартного или специализированного адаптера 220 в интеграционном потоке 540 пользователь должен сконфигурировать его для выполнения определения структуры сообщения объектом 512. Пользователь может сконфигурировать столько адаптеров каждого типа 220, сколько необходимо для обработки всех сообщений, которые пользователю необходимо включить в интеграционные потоки 540. Адаптеры источника 222 извлекают данные из приложений предприятия и производят сообщения, которые они посылают другим интеграционным объектам 530. Точнее, адаптер источника 222 (1) опрашивает или извещается его приложением о событии определенного типа, которое произошло в приложении (например, был введены данные относительно нового клиента); (2) извлекает данные, относящиеся к событию, из приложения; (3) используя команды определения сообщения, создает системное сообщение из данных; и (4) производит сообщение и посылает его одному или нескольким интеграционным объектам назначения 530. Адаптеры назначения 224 получают сообщения от других системных объектов 510, 530 в интеграционных потоках 540 и распространяют данные сообщений к приложениям предприятия 541, 549. А именно, адаптер назначения 224 (1) получает системное сообщение от одного или нескольких интеграционных объектов источника 530; (2) используя команды объекта определения сообщений 512, создает данные для приложения из системного сообщения; и (3) направляет данные в приложение назначения 549,вставляя новые, обновляя старые или удаляя текущие данные соответственно. Адаптеры ответа 226 извлекают данные из приложений предприятия 541, 549 при запросе интеграционными объектами 530, такими как преобразователи 520. А именно, адаптер ответа 226 (1) получает сообщение запроса от интегрированного объекта 530; (2) извлекает требуемые данные из своих приложений предприятия 541,549; и (3) посылает данные преобразователям 520 в сообщении ответа, которое обрабатывается тем же объектом определения сообщений 512, что и сообщение запроса. Адаптеры запроса 228 совместно с преобразователями ответа 522 используются для извлечения данных из приложений предприятия 541, 549 без получения запросов от этих приложений. Как показано на фиг. 7, они находят информацию, которая, как они ожидают, может быть необходима объекту приложения 710, создающему запрос. 34 Например, запрос от объекта приложения 710 может быть столь же прост, как "я хочу видеть данные клиента о погрузке". Все ожидаемые данные, содержащие данные клиента о погрузке, собираются, размещаются в соответствии с той же структурой, которую имел запрос,и "выталкиваются" объекту приложения 710. Более точно, адаптер запроса 228 (1) получает сообщение о запросе от объекта приложения 710; (2) извлекает ожидаемые данные либо непосредственно от другого объекта 540 в системе 100, либо с помощью преобразователя ответа 522, через другой преобразователь ответа 522; и(3) посылает данные объекту приложения 710 в сообщении той же структуры, которую имел запрос, структура которого была определена объектом 512. Хостами для адаптеров 220 являются службы агентов, как более подробно описано ниже. Службы агентов обеспечивают информацию, необходимую адаптерам 220 для соединения с их приложениями (например, пароли и идентификаторы пользователей). Система 100 предоставляет службы агентов для каждого приложения предприятия, которое она может интегрировать. То есть она предоставляет службу агентов для программных продуктов SAPR/3, EntireXBroker и так далее. Система 100 также предоставляет службы агентов для специализированных адаптеров, которые пользователь создает, используя автоматизированное рабочее место ADK 130. Пользователь нуждается в одной службе агентов для каждого приложения предприятия,которое пользователь хочет интегрировать, используя систему 100. Например, если пользователь хочет интегрировать в систему три программных продукта SAP R/3 с одной реляционной базой данных RDBMS, пользователь нуждается в трех SAP R/3 службах агентов и однойRDBMS службе агентов. Каждая служба агентов является хостом для всех адаптеров 220 приложений предприятия, с которым соединяется агент. Объекты определения преобразования 514 задают процесс, который преобразует сообщения, содержащие данные, извлеченные из одного или нескольких приложений, в сообщения,содержащие данные, необходимые одним или нескольким приложениям. Преобразователи 520 реализуют данные, полученные от объектов определения преобразования 514, собирая входные сообщения от объектов источников, преобразуя данные и посылая выходные сообщения объектам назначения. Процесс преобразования,который составляется с помощью алгоритма определения преобразования 514, всегда вовлекает, по крайней мере, два типа сообщений: первичное входное сообщение и одно или несколько выходных сообщений, как показано на фиг. 8. 35 Первичное входное сообщение обычно содержит большинство или все данные, которые пользователь хочет разместить в выходных сообщениях для приложений назначения. Выходные сообщения содержат данные входных сообщений, преобразованных должным образом для приложений назначения. Когда пользователь создает объект для определения преобразования 514, он сначала указывает в 805 имя первичного входного сообщения. Затем в 810 пользователь идентифицирует определение сообщения 512 (т. е. его структуру), которое задает ему ту структуру сообщений, с которой он будет работать. Любые дополнительные входные сообщения, данные из которых будут необходимы позднее, определяются в 815. Затем пользователь идентифицирует в 820 определения этих дополнительных сообщений 512. Один процесс преобразования данных может генерировать любое количество выходных сообщений. Соответственно пользователь должен указать эти выходные сообщения в 825 и идентифицировать определения этих сообщений 512, которые полностью задают параметры выходного сообщения. Пользователь затем создает начинающуюся в 835 последовательность этапов 840, 845, 850, 855, 860, 865,которые определяют, когда читать входные данные, как преобразовывать входные данные,как отобразить входные данные в выходных определениях сообщений на основе определения входных сообщений, а также когда записать преобразованные данные в фактические выходные сообщения. Пользователь преобразует входные данные любым способом, необходимым для создания выходных сообщений, которые ему требуются. Например, пользователь может создавать выражение преобразования, которое указывает объединение единичного элемента сообщения, содержащего имя клиента, и единичного элемента сообщения, содержащего фамилию клиента,потому что приложение назначения требует полного имени клиента в одном поле данных. Или пользователь создает выражение преобразования, указывающее выбор только некоторых символов из единичного элемента сообщения или дополнения единичного элемента сообщения пробелами, с тем, чтобы сделать его длину правильной для соответствующего поля данных в приложении назначения. Пользователь затем генерирует различные выходные сообщения,записывая их в различных точках в процессе преобразования. Когда первичное входное сообщение не содержит все данные, которые необходимы для производства выходных сообщений, пользователь может организовать получение дополнительных данных, используя процедуру сообщений запроса/ответа. Например, предположим,что первичное входное сообщение, которое пользователь использует в определении преоб 003744 36 разования, использует сокращения для штатов США (например, VA для Вирджинии). Примем, например, что приложение назначения требует полных названий штатов. Чтобы получить полные названия штатов, необходимые для производства выходных сообщений,пользователь должен создать такую процедуру создания сообщения запроса/ответа, чтобы можно было посылать сокращения приложению, которое в ответ пришлет ему названия штатов. После создания пользователем определения преобразования 514 пользователь может протестировать его, чтобы удостовериться, что оно содержит проверенные данные в выходном сообщении, перед использованием его в интеграционном потоке. Пользователь может затем присвоить определение преобразования одному или нескольким преобразователям 520. Преобразователь 520 выполняет определение преобразования 514. Когда пользователь создает преобразователь 520, он указывает объекты 510, 530 для использования в качестве источников первичных входных сообщений и объекты 510, 530, которые должны быть объектами назначения для выходных сообщений. Пользователь также указывает объекты, которые должны отвечать на запросы для поддержки создания входных сообщений. Когда преобразователь 520 получает первичное входное сообщение от объекта источника 540, он выполняет последовательность этапов, которые создаются на основе определении преобразования 514, что и составляет процесс преобразования. Затем он читает первичные и необходимые дополнительные входные сообщения, преобразует входные данные, записывает преобразованные данные в одно или несколько выходных сообщений и посылает выходные сообщения объектам назначения 540. Типичный процесс преобразования показан на фиг. 9. Преобразователь 520 получает первичное входное сообщение 920 от концентратора 518. Затем он получает необходимое дополнительное входное сообщение 940 от адаптера ответа 226. Наконец, преобразователь 520 посылает два различных выходных сообщения 960, 980 двум различным адаптерам назначения 224. Концентраторы 518 являются зонами хранения сообщений для адаптеров 220 и преобразователей 520. Концентраторы 518 позволяют адаптерам 220 и преобразователям 520 обмениваться сообщениями асинхронно (т.е. не в режиме реального времени), что упрощает связь между объектами. Например, пользователь может иметь адаптер источника 222, который производит сообщения для преобразователя 520. Пользователь может захотеть, чтобы адаптер 222 производил и посылал свои сообщения независимо от того, готов ли преобразователь 520 к их получению. Пользователь может настроить адаптер 222 для посылки его сообщений кон 37 центратору сообщений 518 и настроить преобразователь 520 для получения сообщений адаптера от концентратора 518. Система 100 затем доставит сообщения от концентратора 518 к объекту назначения 540, когда объект назначения будет готов получить их. Кроме того, пользователь может иметь три адаптера источника 222, посылающих сообщения на основе одного определения сообщения 512 к пяти объектам назначения 224, 520. Если пользователь не использует концентратор 518(как показано на фиг. 10(а, пользователю придется создать, в целом, пятнадцать связей между объектами. С другой стороны, если пользователь использует концентратор 518 (как показано на фиг. 10(b, ему придется создать и поддерживать только восемь связей. Концентраторы сообщений 518 могут содержать только один тип сообщений (то есть сообщения, которые полностью заданы на основе определения сообщения 512). Объекты назначения концентраторов 518 подписаны на определенные сообщения в течение длительного времени. Система 100 следит за сообщениями, которые каждый объект назначения 224, 520 получил от концентратора 518, так же как и за теми, которые объекты назначения 224, 520 еще не получили. Если объект назначения 224, 520 становится неактивным, система 100 запоминает последнее сообщение, которое получил объект назначения 224, 520. Когда объект назначения 224, 520 затем становится активным, система 100 доставляет только те сообщения, которые объект назначения 224, 520 еще не получал. Если бы подписки концентратора не были длительными,объекты назначения 224, 520 получили бы сообщения, которые достигли концентраторов 518, в то время как объекты назначения 224, 520 были бы активны, но никогда не получили бы сообщения, которые достигли концентраторов 518, когда объекты назначения 224, 520 были неактивны. Пользователь может выбирать из двух стилей передачи сообщений, используемых системой 100 при доставке сообщений от концентратора 518: (1) двухточечный, где система 100 доставляет каждое сообщение первому доступному объекту назначения только; или (2) публикация/подписка, где система 100 доставляет каждое сообщение каждому объекту, который пользователь идентифицировал как объект назначения концентратора 518. Если пользователь хочет удалить некоторые данные из части интеграционного потока 540, то он должен использовать фильтр 516. Фильтр 516 содержит критерии, которые анализируют данные в сообщении, и если данные этому критерию не соответствуют, то их удаляют. Когда пользователь хочет отфильтровать некоторый тип сообщений, он создает определение фильтрации 516 и присваивает его одной 38 или нескольким связям между объектами 540,которые обрабатывают этот тип сообщений. Система 100 применяет критерии, находящиеся в фильтрах 516, ко всем сообщениям, посланным по этим связям. Например, рассмотрим ситуацию, в которой концентратор 520 посылает сообщения, содержащие данные о новых клиентах адаптеру назначения 224. Пользователь может желать,чтобы только данные о клиентах, которые еще не заплатили, достигали адаптера назначения 224. Чтобы выполнить это, пользователь создает фильтр 516, который определяет критерий "Состояние=Оплачено", и присваивает его связи между концентратором 518 и адаптером назначения 224. Пользователь может создавать один или более фильтров 516 для каждого определения сообщения 513 в интеграционном потоке 540. Пользователь может назначать применение фильтра 516 ко множеству связей, или пользователь может назначать применение фильтра 516 для сообщений одного типа различным связям. Например, рассмотрим ситуацию, в которой концентратор 518 посылает сообщения, содержащие данные о новых клиентах, на два адаптера 220. Пользователь может задать, чтобы один адаптер 220 получал только данные о клиентах, которые заплатили, а чтобы другой адаптер 220 получал только данные о клиентах, которые еще не заплатили. Пользователь, таким образом, создает два фильтра 516. Один задает критерий "Состояние=Не оплачено", а другой "Состояние=Оплачено". Затем пользователь назначает применение фильтра 516 соответствующей связи. Когда пользователь создает определенные фильтры 516 для сообщений, которые не содержат таблиц данных, критерии, определенные пользователем, действуют на все сообщение. Все сообщение или удовлетворяет критерию фильтра и остается в потоке, или не удовлетворяет и отбрасывается. Когда пользователь создает фильтр 516 для сообщений, которые содержат таблицы данных, пользователь может определить критерии, которые затрагивают как все сообщение, так и только данные в пределах таблиц. Если пользователь указывает критерии для единичных элементов сообщения в секции 620, все сообщение или удовлетворяет критериям и остается в потоке, или не удовлетворяет и отбрасывается. Если пользователь указывает критерии для единичных элементов сообщения в таблице 640, сообщение остается в потоке только с теми строками данных, которые удовлетворяют критериям. Строки, которые не удовлетворяют критериям, отбрасываются. Например, рассмотрим ситуацию, в которой сообщение содержит таблицу 640 с девятью строкамиданных, каждая для одного из девяти новых клиентов. Если пользователь устанавли 39 вает определение фильтра 516, который отфильтровывает клиентов, потративших 1000 или меньше, то строки, содержащие данные о клиентах, которые потратили больше чем 1000,остаются в потоке, в то время как строки, содержащие данные о клиентах, которые потратили 1000 или меньше, будут отбрасываться. После того как пользователь создал фильтр 516, он может протестировать его, чтобы удостовериться в том, что он работает должным образом, перед использованием его в интеграционном потоке 540. Как только появляются системные объекты, которые пользователь хочет использовать в интеграционном потоке 540, пользователь может указать, как он хочет, чтобы система 100 обрабатывала сообщения о них и для них. Чтобы это сделать, пользователь устанавливает связи между интеграционными объектами 530. Каждая связь устанавливает один объект в качестве источника и другой в качестве объекта назначения или один объект в качестве запрашивающего и другой в качестве отвечающего. Адаптеры источника всегда являются источниками сообщений. Они могут посылать сообщения адаптерам назначения того же самого типа в службе агентов (например, адаптер источника программного продукта SAP R/3 может посылать сообщения адаптеру назначения SAP R/3),концентраторам сообщений 518 и преобразователям 520. Преобразователи 520 могут быть объектами назначения, запрашивающими объектами и источниками. Они могут получать первичные входные сообщения 920 от адаптеров источника 222, концентраторов сообщений 518 и других преобразователей 520. Они также могут запрашивать поддерживающие входные сообщения 940 от адаптеров ответа 226 и концентраторов сообщений 518 и посылать выходные сообщения 960, 980 адаптерам назначения 224, концентраторам 518 и другим преобразователям 520. Концентраторы сообщений 518 могут быть объектами назначения и источниками. Адаптеры назначения 224 всегда являются объектами назначения. Они могут получать сообщения от адаптеров источника 222 того же самого типа в службе агентов, от концентраторов 518 и от преобразователей 520. По умолчанию, система 100 использует"сохранность сообщений". То есть она записывает каждое сообщение, которое она доставляет от одного интеграционного объекта 530 к другому, в устойчивой памяти в том месте, которое задает пользователь. Если происходит системный отказ во время передачи сообщения, система 100 может восстановить сообщение из памяти, а когда система восстановится, то доставить сообщение его объектам назначения. Поскольку сохранность сообщений увеличивает системные затраты, система 100 позволяет пользователю отключать сохранность для 40 любого интеграционного объекта 530. Однако в этом случае, если происходит системный отказ во время передачи сообщений к или от этого объекта, то эти сообщения могут быть потеряны. Система 100 предоставляет другие связанные с доставкой опции, которые помогают пользователю управлять своими системными ресурсами. Система 100 поддерживает зоны хранения сообщений для каждого интеграционного объекта в интеграционном потоке. Пользователь может также задавать размеры этих зон хранения. Пользователь может ограничивать число сообщений, которые система 100 одновременно хранит для каждого объекта, и пользователь может ограничивать отрезок времени хранения системой 100 каждого сообщения. Если интеграционный объект 530 производит сообщения быстрее, чем объекты назначения могут получать их, эти ограничения могут предохранять зону хранения объекта от переполнения. Пользователь разрабатывает все интеграционные потоки проекта с помощью автоматизированного рабочего места ADK 120. Все интеграционные потоки, которые пользователь разрабатывает и сохраняет (то есть объекты определения 510 и интеграционные объекты 530,которые пользователь создает и связывает между собой), сохраняются в архиве 140. Проект является логической структурой, которая обеспечивает пользователю доступ к архиву 140. Любая инсталляция системы 100 имеет, по крайней мере, один проект и одну архивную службу (архив) 140. Далее будут представлены общая структура и проектная философия объекта сообщения,используемого всеми производителями сообщений в системе 100. Модель сообщений, которая приводится здесь, имеет возможность неограниченного расширения и полезна для преобразования как форматов исходных файлов в сообщения, так и для преобразования сообщений в форматы этих файлов, а также для посылки внутренних сообщений от узла к узлу в системе 100. Сообщения имеют приоритет и строятся на основе парадигмы пара имя/значение (или заголовок/данные) для представления данных. Данные, представленные моделью сообщений согласно настоящему изобретению, всегда являются объектами. Они являются экземпляром объекта Java некоторого класса. Каждый узел данных безопасен по типу в том смысле, что он может содержать только данные определенного класса. Структура сообщений управляется метаданными. То есть правильно созданные сообщения всегда формируются с использованием схемы,находящейся в объекте, который является определением сообщения 512. Каждое сообщение некоторого "типа" сформировано на основе одного определения сообщения 512. Определение сообщения 512 представляет собой экземпляр 41 сообщения, хотя его узлы были расширены с тем, чтобы содержать информацию о том, как формировать экземпляры в формате, который оно описывает, так же как и необязательную информацию о том, как конвертировать данные к и из собственного формата файла приложения. Как кратко отмечено выше, сообщение 600 является совокупностью простых и составных объектов с древовидной структурой. Все объекты, которые могут появляться в сообщении, являются различного типа составляющими сообщения. В предпочтительной реализации изобретения составляющей сообщения может быть один из следующих типов объектов: (1) элемент данных; (2) элемент массива; (3) табличный элемент; и (4) секционный элемент или"связь сообщений". Сообщение всегда имеет единственный секционный элемент наверху дерева, называемый "секцией верхнего уровня". Эта и другие секции могут содержать экземпляры любого из четырех типов элементов. Элемент данных содержит "атомарные" данные, хотя данные инкапсулированы в классJava. Например, целочисленные данные хранятся в java. lang. Integer объекте, информация дата/время инкапсулирована - в java. util. Calendar объект и т.д. Элемент массива является совокупностью одного или нескольких примитивных элементов. Длина массива определена в метаданных, хотя эта длина может быть определена как допустимый диапазон, и в этом случае длина определяется при разборе собственной записи файла приложения. Табличный элемент фактически является изоморфной совокупностью секционных элементов, что означает, что каждая "строка" таблицы является секцией, содержащей одинаковую комбинацию имен и типов. Он также имеет описание диапазона, который может иметь переменную длину. Параметр связь в определении сообщения является важным постоянным параметром, который играет важную роль при объединении форматов сообщений. Он полезен, когда необходимо произвести переопределение сообщения. Сообщение может представлять необязательные данные, так же как и значения по умолчанию, жестко заданные в соответствии с определением сообщения. Самое простое сообщение создается как пустое обобщение путем вызова методом обработки сообщения определенного класса. Он создает сообщение со всеми надлежащими парами имя/значение (т.е. структурой), но каждый элемент данных имеет нулевое значение. Только один конструктор экспортирует сообщения для всеобщего применения, проверяя только структуру сообщения, гарантируя его надлежащую форму. Интерфейс API сообщений задает порядок доступа к элементам сообщения либо через поиск по имени, либо через секционные итераторы (разделители). Здесь следует отметить, что сообщение поддерживает иерархическую структур имен, используя конфигурируемый ограни 003744 42 читель, обеспечивая полный или относительный"путь по имени" для доступа к любому компоненту в иерархии. Секция 620 является группой неповторяющихся элементов сообщений. Название такого секционного элемента не содержит фактических данных, а, вместо этого, задает название группы элементов сообщений, которые содержат данные (то есть они содержат единичные элементы 660). Секции 620 могут содержать любую комбинацию типов элементов сообщения. Таблица 640 является группой секционных элементов, называемых строками, которые могут повторяться любое число раз. Названия таблиц также не содержат фактических данных. Таблицы содержат элементы сообщений, которые содержат данные (то есть они содержат единичные элементы). Таблицы 640 могут содержать любую комбинацию типов элементов сообщения. Единичный элемент 660 является элементом сообщения, который содержит данные. Единичные элементы 660 являются элементами сообщения самого низкого уровня в иерархии определения сообщения. Они не могут содержать другие элементы сообщений. Пользователь разрабатывает все интеграционные потоки 540 проекта с помощью автоматизированного рабочего места ADK 120. Эти интеграционные потоки 540, которые пользователь разрабатывает и сохраняет (то есть определение 610 и интеграционные объекты 620, которые пользователь создает и связывает между собой) сохраняются в архиве 140. Проект является логической структурой, которая позволяет пользователю просматривать архив 140. Каждая инсталляция системы 100 имеет один проект и один архив 140. Другим важным аспектом настоящего изобретения является то, что система 100 является распределенной системой вычислений. То есть пользователь может запускать выполнение системных компонентов, которые составляют систему 100, на одной или нескольких физических машинах (то есть хост-компьютерах), но все компоненты работают вместе как одно приложение. Узел является физическим процессом,который выполняется на хосте и поддерживает одну или несколько служб. Каждый узел является виртуальной машиной Java (JVM) и распознается операционной системой как процессjavaw.exe. Пользователь должен создать, по крайней мере, один узел для каждого хоста при подключении к приложению предприятия, которое пользователь хочет интегрировать. Пользователь может иметь столько узлов, сколько диктуют требования его бизнеса. Имеются два приоритетных интерфейса в системе 100: (1) интерфейсы, загруженные в автоматизированное рабочее место ADK 120; и(2) административная консоль 160. Автоматизированное рабочее место ADK 120 является ин 43 струментом для создания и изменения интеграционных потоков 540, в то время как административная консоль 160 создает связи между системными узлами и службами. Они более подробно описаны ниже. Создание интеграционного потока 540 в соответствии с настоящим изобретением может быть выполнено следующим образом. Пользователь сначала должен получить службы агентов от системы 100. На административной консоли 160 пользователь затем конфигурирует системные узлы каждой хост-машины, на которой выполняется приложение, которое пользователь хочет интегрировать в систему. Затем пользователь конфигурирует требующиеся службы на узлах, включая службу агентов для каждого приложения, которое пользователь собирается интегрировать. Чтобы спланировать интеграционный поток, пользователь должен определить следующие факторы. Например, пользователь должен определить типы данных, которые пользователь должен извлечь из приложений и распространить к приложениям. Пользователь должен также рассмотреть (1) как пользователь хочет направить сообщения между системными объектами; (2) как пользователь должен преобразовать данные от одного приложения, так чтобы они могли использоваться другими приложениями; и (3) должен ли пользователь устанавливать фильтры для некоторых данных из потока. На автоматизированном рабочем месте 120 пользователь должен сначала создать проект, а затем создавать интеграционный поток следующим образом. Сначала пользователь должен сконфигурировать адаптеры 220 для взаимодействия с приложениями пользователя и создать определения сообщений 512, которые необходимы пользователю для формирования сообщений, который будут использоваться в интеграционном потоке 540. Эти определения сообщений 512 затем должны быть протестированы,чтобы удостовериться, что сформированные сообщения соответствуют поставленной задаче. Затем пользователь должен создать концентраторы 518 для хранения сообщений от адаптеров 220 и преобразователей 518. Пользователь может затем создавать определения отображения 514 для преобразования сообщений от приложения источника 541 в сообщения для приложения назначения 549. Кроме того, пользователь может создавать типовые входные сообщения 920, 940 и использовать их для тестирования каждого определения отображения 514,чтобы удостовериться, что оно производит надлежащие выходные сообщения 960, 980. Затем пользователь должен создать преобразователи 520, необходимые для осуществления определений отображения 514. Необходимо, чтобы адаптеры 220, преобразователи 520 и концентраторы 626 были связаны. Если пользователь должен отфильтровать некоторые дан 003744 44 ные из потока 540, то он должен затем создать фильтры 516. Предпочтительно используя типовые сообщения, пользователь должен затем протестировать фильтры 516, чтобы удостовериться, что они отфильтровывают надлежащие данные. Затем пользователь может присвоить фильтры 516 связям между объектами. На автоматизированном рабочем месте 120 пользователь должен затем проверить правильность интеграционного потока 540 и исправить его при необходимости. Пользователь может затем сохранить и закрыть проект. На административной консоли 160 пользователь должен затем сконфигурировать журнал событий с тем,чтобы пользователь мог просматривать сообщения о действиях системы. Если пользователь хочет просмотреть статистику действий системы (например, число сообщений, произведенных за определенные интервалы времени индивидуальными преобразователями), пользователь должен затем сконфигурировать средство просмотра статистики. Вновь на административной консоли 160 пользователь может запустить интеграционный поток путем загрузки соответствующих системных узлов и служб, включая службы агентов приложений, которые пользователь собирается интегрировать. Затем, пользователь будет проверять журнал событий и статистику, чтобы удостовериться, что интеграционный поток 540 выполняется должным образом. Если пользователь должен сделать изменения в интеграционном потоке 540, то он должен соответственно остановить соответствующие службы на административной консоли 160, изменить интеграционный поток 540 на ADK 120 и перезапустить службы на административной консоли 160. Нижеследующее описывает специалисту процедуры, которые могут использоваться с мастером адаптера источника, мастером адаптера назначения и мастером адаптера ответа, в соответствии с настоящим изобретением для надлежащей конфигурации адаптера 220. Обычно имеется четыре отдельных процесса. Первый процесс должен иметь следующие этапы: (1) назвать адаптер 200; (2) выбрать службу агентов, являющуюся хостом адаптера 220; и (3) выбрать определение сообщения 512 для сообщений, которые адаптер 220 должен производить, получать или на которые отвечать. Второй процесс должен иметь следующие этапы: (1) выбрать определенный адаптер 220, который должен быть сконфигурирован (то есть стандартный или специализированный); (2) обеспечить информацию о соединении; и (3) обеспечить информацию о реализации. Чаще всего, этап обеспечения информацией реализации включает этап извлечения определения сообщения 512 адаптера 220. Третий процесс зависит от типа создаваемого адаптера 220. Если создают адаптер источника 222, то нужно указать объекты назначения, 45 которым адаптер 222 будет посылать сообщения. С другой стороны, если создают адаптер назначения 224, то нужно указать источники, от которых адаптер 224 будет получать сообщения. Если создают адаптер ответа 226, кроме того,нужно указать запрашивающие объекты (то есть преобразователи 520), которым адаптер 226 будет посылать сообщения ответа. Нужно, наконец, указать опции доставки(например, срок продолжительности жизни сообщения) для сообщений адаптера. Однако,прежде чем можно будет создавать адаптер 220,на административной консоли 160 должна существовать служба агентов, которая будет хостом адаптера. Например, прежде чем можно создавать адаптер программного продукта EntireXBroker, должна существовать служба агентов для EntireX Broker. Если хотят также указать источник, объект назначения или объекты запроса для адаптера 220, используя мастер адаптера, то эти объекты должны существовать перед открытием мастера адаптера. Ссылаясь вновь на фиг. 4(а) и 4(b), агентадаптеры 200 взаимодействуют с ресурсами приложения, с одной стороны, и с инфраструктурой системы 100, с другой. С одной стороны,адаптерная половина каждого агент-адаптера 200 использует API определенного ресурса приложения или любой другой доступный интерфейс. С другой стороны, сторона агента соответствует модели событий и сообщений системы 100, как более подробно описано ниже. Совместно агент и адаптер сглаживают различия в протоколах интерфейса и структурах данных,обеспечивая однородные, нормализованные бизнес-события, которые они публикуют и потребляют. В отличие от других решений интеграции приложений, архитектура адаптера, допускающая расширение, обеспечивает способность бесшовного приспособления к интерфейсам приложения, при поддержке текущего набора основных интерфейсов. Это особенно важно для систем, которые уже выпущены и много лет присутствуют на рынке. Например, комплексное приложение имеет основной набор интерфейсов А', которые поддержаны некоторой версией агент-адаптера 200. Если новая версия приложения, предназначенного для информационной поддержки процессов подготовки производства, включает новый набор интерфейсов А",то пользователь может захотеть одновременно адаптироваться к старым интерфейсам А' производственной среды. Благодаря этим возможностям возрастающие изменения в интеграционной среде могут быть бесшовно согласованы. Каждый компонент системы 100 может поддерживаться любой из известных платформ,причем агент-адаптеры 200 гибко расширяют это свойства на все интегрированные приложения. Ключевые компоненты системы 100 (например, агент-адаптеры 200 или интеграцион 003744 46 ный сервер 26) могут, таким образом, быть расположены вместе с приложениями, или иметь дистанционный доступ, или и то, и другое. Возможны многочисленные конфигурации развертывания - среда оптимизирована для сбалансирования работоспособности, производительности и административных требований. Много стандартных адаптеров 200 поставляются с системой 100, включая такие программные продукты, как SAP, MQSeries, ENTIREBroker, RDBMSCICS. Также адаптеры 200 поддерживают быстрое внедрение и облегчают интеграцию этих информационных ресурсов. Они также уменьшают время на обучение и получение необходимых навыков работы. ADK 130, имеющий набор шаблонов и мастеров автоматизации, обеспечивает высокую производительность. Он приспособлен к интегрированным средам разработки любого пользователя, что способствует легкой настройке поставляемых адаптеров и разработке специализированных интерфейсов. Адаптеры 200 созданы с популярными языковыми и интерфейсными привязками,включая C, Java, EJB, CORBA, СОМ и Natural. Таким образом, они подключаются в среду и к инструментальным средствам любого пользователя. Они усиливают внутреннюю экспертизу языка, и они приспосабливаемы к сложным требованиям интерфейса ресурсов. Архитектура агент-адаптера согласно настоящему изобретению обеспечивает, таким образом, устойчивое средство интеграции приложения и обладает значительно большими возможностями, чем простейшие интерфейсы. Она гарантирует однородность событий для всех ресурсов системы. Подсистема агент-адаптера включает модули интерфейса времени выполнения, которые соединяют внешние приложения с EAI. На стороне адаптера это физический интерфейс с внешним приложением. Сторона агента действует как хост для адаптера, управляет ресурсами и публикует события от имени адаптера. Основные классы адаптеров в системе 100 следующие. Класс "главного адаптера" обеспечивает способность адаптера для самостоятельного запуска и обработки его определений конфигурации. Он также ответственен за создание экземпляров классов, используемых четырьмя возможными типами соединений адаптеров. Класс "адаптера приемника" обеспечивает способность адаптера получить документ от EAI и передать его стороннему пакету. Класс "адаптера отправителя" обеспечивает способность адаптера получить документ от стороннего пакета и передать его EAI. Класс "адаптера ответа" обеспечивает способность адаптера получить документ от EAI, передать его стороннему пакету, получить ответ от стороннего пакета,упаковать и возвратить ответ EAI для обработки. Класс "адаптера запроса" обеспечивает способность адаптера получить документ от стороннего пакета, передать его EAI для обработки, 47 получить ответ от EAI и возвратить ответ стороннему пакету. Интерфейс агент-адаптера EAI согласно настоящему изобретению реализован адаптером, осуществляющим несколько интерфейсовJava, тогда как интерфейс адаптера к агенту реализован адаптером, использующим известные методы компонентов узел/агент. Согласно другому важному аспекту настоящего изобретения каждый адаптер должен реализовать следующий интерфейс. Для AdapterBridge методinitialize(Agent-adapterConfig) вызывается агентом во время инициализации и используется адаптером для самозагрузки. Шлюз адаптера находится внутри метода, при помощи которого адаптер 220, 220', 220" должен запросить агента 210, чтобы определить, какие определения документа должны быть обработаны, и тип обработки, предусмотренный для каждого документа. Это выполняется с использованием следующих методов агента:getResponseDocumentDefinitions Этот метод затем будет разбирать документ AdapterConfiguration, чтобы определить подраздел, имеющий отношение к специфическому определению документа, скрывающий специфическую информацию о конфигурации документа, и создаст экземпляр определенного класса на основе типа обработки (передача,прием, запрос или ответ). Впоследствии он или запустит поток (Тhrеаd) (передача или запрос),выпустит Agent.setReceiveListener (прием), или выпустит Agent.setResponseListener (ответ) с тем, чтобы регистрировать обратные вызовы(callbacks) агента, которые будут вызваны по прибытии сообщений.Restart метод вызывается агентом 220,220', 220" с тем, чтобы адаптер 210 завершил всю деятельность, перезагрузил конфигурационные данные и перезапустился. Shutdown метод вызывается агентом 220, 220', 220" во время обработки завершения работы. Следующие интерфейсы также реализованы адаптерами 220, как описано ниже. Для интерфейса ReceiveListeneronReceiveMessage(ReceiveData) метод вызывается агентом 210 при получении JMS сообщения, и его агент будет передавать документ адаптеру для обработки. Эта обработка будет происходить под управлением сеансового потока JMS. Обработка адаптера будет, в основном, состоять из направления документа стороннему программному приложению c использованием интерфейсов, предоставленных приложением. Тем не менее, следует отметить, что при этом типе вызова от приложения не ожидается никакого ответа. Адаптер 220, 220', 220" будет ожидать от приложения 48 только ответ об успехе или отказе. Если EAI ожидает фактического ответа от сторонней системы, вместо него должен использоваться интерфейс ResponseListener. Для интерфейса SendListeneronSendTimerEvent(SendData) метод вызывается агентом 210, если адаптер 220, 220', 220" использует средство таймера узла/агента. Это средство полезно, когда сторонний интерфейс не имеет никакого способа для уведомления о событии для документов,посланных EAI для обработки. Для интерфейса RequestListeneronRequestTimerEvent(RequestData) метод вызывается агентом 210, если адаптер 220, 220', 220" использует средство таймера узла/агента. Это средство полезно, когда сторонний интерфейс не имеет никакого механизма для уведомления о событии для документов,посланных EAI для обработки. Однако в данный момент следует отметить, что интерфейс RequestListener отличается от интерфейсаSendListener в том, что он будет посылать документ EAI и будет ждать документ в ответ. Этот ответ затем будет передан обратно сторонней системе. Для интерфейса ResponseListeneronResponseMessage(ResponseData) метод вызывается агентом 210 при получении JMS сообщения, и агент 210 передаст документ адаптеру 220, 220', 220" для обработки. Эта обработка будет происходить под управлением сеансового потока JMS. Обработка адаптера будет состоять из направления документа стороннему программному приложению с использованием интерфейсов, обеспеченных приложением, и затем посылки ответа назад в систему 100 для дополнительной обработки. Однако, если система 100 не ожидает фактического ответа от сторонней системы, вместо него должен использоваться интерфейс ReceiveListener. Когда пользователь инсталлирует систему 100, основным компонентом, который он инсталлирует, является менеджер узлов 1210, как показано на фиг. 12. Менеджер узлов 1210 является виртуальной машиной Java (JVM), которая обеспечивает службы для всех других узлов и служб, которые пользователь инсталлирует в системе. Системная инсталляция автоматически создает службу репозитория 1220, службу интерфейса пользователя (UIS) 1230 и службу контроля 1240 на машине, являющейся хостом менеджера узлов 1210. Прежде чем пользователь сможет запустить сеанс клиента 1205 (например, административную консоль 160 или интеграционные инструментальные средства 120), он должен запустить менеджер узлов 1210. Как отмечено выше, менеджер узлов 1210 автоматически запускает службу репозитория 1230 и UIS 1240. В противном случае, пользователь не может использовать административную консоль 160 или 49 интеграционные инструментальные средства 120, если эти службы не выполняются. В зависимости от конкретной задачи, выполняемой пользователем на административной консоли 160 или на интеграционных инструментальных средствах 120, могут потребоваться другие службы. Как только менеджер узлов 1210 запущен,пользователь должен конфигурировать системные узлы и службы, включая службы агентов 1250 для приложений, которые пользователь хочет интегрировать. Пользователь сначала их инициирует, используя сеанс административной консоли 160. Пользователь может затем запустить сеанс интеграционных инструментальных средств 120 и начать разрабатывать интеграционные потоки 540, как показано на фиг. 5(с). Когда пользователь закончит разработку этих интеграционных потоков 540, он может запустить их, запуская узлы и службы из сеанса административной консоли 160. Когда пользователь запускает клиентский сеанс, он идентифицирует менеджер узлов 1210 в качестве сервера клиента 1215. Пользователь может соединять столько сеансов интеграционных инструментальных средств 120 и административной консоли 160 с менеджером узлов 1250, сколько диктуют требования бизнеса пользователя. Все эти сеансы интеграционных инструментальных средств 120 и административной консоли 160 будут доступны только для чтения. Сеансы консоли, соединенные с менеджером узлов 1250, имеют доступ к содержанию службы репозитория 520, которая выполняется на этом менеджере узлов 1210. При работе с системой 100 пользователь должен запустить менеджер узлов 1210, сеанс административной консоли 160 и сеанс интеграционных инструментальных средств 120. Узлы. Как отмечено выше и показано на фиг. 13(а)-(с) совместно с фиг. 12, узел 1310 является физическим процессом, который выполняется на хосте 1300 и поддерживает одну или несколько служб. Каждый узел 1310 является виртуальной машиной Java (JVM) и распознается операционной системой как процесс javaw.exe. Пользователь должен создать, по крайней мере,один узел 1310 для каждого хоста 1300, который выполняет приложение для предприятия, которое пользователь хочет интегрировать. Пользователь может иметь столько узлов 1310, сколько диктуют требования бизнеса пользователя. Служба является объектом, который обеспечивает функциональные возможности продукта. Система 100 обычно включает системные службы и службы приложений. Клиентский графический интерфейс пользователя (GUI),такой как интеграционные инструментальные средства 120 и административная консоль 160,позволяет пользователю работать с системой 100. Клиенты 1205 (фиг. 12) могут работать на 50 том же самом физическом хосте 1300, на котором выполняются узлы 1310 и службы, или они могут работать на различных хостах 1200. Каждое предприятие должно также иметь менеджер узлов 1210. Менеджер узлов 1210 предоставляет службы для всех других узлов 1310 в системе 100. Он выполняет службу интерфейса пользователя (UIS) 1230 и службу репозитория 1220. Фиг. 13(а) иллюстрирует среду,имеющую три хоста 1300. Xocт 1 выполняет менеджер узлов 1210, в то время как Хост 1 и Хост 2 выполняют узлы 1310. Система 100 является совокупностью системных служб и служб приложений. Системные службы поддерживают узлы и службы. Например, служба контроля 1240 сохраняет системные данные времени выполнения для узлов 1310 и служб. Службы приложения обеспечивают функциональные возможности системы 100. Например, службы агентов CICS поддерживают адаптеры, которые должны соединяться с приложениями CICS. Системные службы. Системные службы согласно настоящему изобретению обычно включают службу интерфейса пользователя (UIS) 1230, службу репозитория 1220 и службу контроля 1240. Точнее,UIS 1230 обеспечивает средства, необходимые для выполнения клиентских компонентов (то есть интеграционных инструментальных средств 120 и административной консоли 160). Аналогично, служба репозитория 1220 сохраняет конфигурации для всех сконфигурированных служб и объектов 540 интеграционного потока. Наконец, служба контроля 1240 сохраняет системные данные времени выполнения, включая системные журналы событий и статистическую информацию. Службы приложений. При рассмотрении вновь фиг. 12 может быть отмечено, что службы приложений, используемые в системе 100, включают службу передачи сообщений предприятия (EMS) 1260,которая позволяет системе 100 использовать режимы множественной передачи сообщений,включая двухточечный, публикации/подписки и передачу сообщений запрос/ответ. EMS 1260 также поддерживает концентраторы сообщений и обеспечивает сохранность сообщений. Службы приложений включают также интеграционную службу (integration service) (IS) 1270, которая позволяет системе 100 преобразовывать сообщения, включая разбиение сообщений, объединение сообщений и манипуляцию данными сообщений. Дополнительно IS 1270 поддерживает преобразователи. RMI (remote method invocation) производственные службы (не показаны) могут дополнительно использоваться в качестве служб приложений для управления удаленным вызовом методов (RMI), связанных с внешними приложениями. Службы маршрутизации 1280 включают также службу приложений, которая 51 позволяет системе 100 направлять сообщения через систему, на основе содержания сообщения, включая фильтрацию содержания сообщения согласно критериям, которые определяет пользователь, и определение достоверности сообщений. Служба маршрутизации 1280 также поддерживает фильтры. Службы агентов 1250 поддерживают адаптеры. Пользователь должен инсталлировать службу агентов на каждом хосте 600, который выполняет приложение для предприятия, которое пользователь хочет интегрировать. Как показано на фиг. 13(b), Хост 1 и Хост 2 выполняют службы. Хост 3 не может выполнять службы, потому что он не имеет узла 1310. Клиенты. Система 100 включает двух клиентов GUI,которые позволяют пользователю работать с интеграционными потоками 540. Клиенты могут работать на любом хосте 1300, независимо от того, выполняет ли хост 1300 менеджер узлов 1210, выполняет ли узлы 1310 и службы или не выполняет никаких узлов 1310 или служб. Пользователь может инсталлировать столько клиентов, сколько диктуют требования бизнеса пользователя. Например, пользователь мог бы захотеть инсталлировать клиенты 1205 на сетевом хосте, чтобы работать с интеграционными потоками пользователя 540 из удаленного местоположения. На фиг. 13(с) и Хост 2, и Хост 3 выполняют клиентов административной консоли 160 и интеграционных инструментальных средств 120. Хост 1, с другой стороны, не выполняет клиентов ни административной консоли 160, ни интеграционных инструментальных средств 120. В системе 100 имеется два основных интерфейса: инструментальные средства 120 и административная консоль 160. Инструментальные средства 120 предоставляют инструменты для создания и изменения интеграционных потоков 700, в то время как административная консоль 160 предоставляет инструменты для управления системными узлами и службами. Они более подробно описаны ниже. Создание интеграционного потока 700 в соответствии с настоящим изобретением может быть выполнено следующим образом. Пользователь сначала должен получить службы агентов от системы 100. На административной консоли 160 пользователь затем конфигурирует системные узлы каждой хост-машины, на которой выполняется приложение, которое он хочет интегрировать. Затем пользователь конфигурирует требуемые службы узлов, включая службу агентов для каждого приложения, которое пользователь собирается интегрировать. Для планирования интеграционного потока пользователь должен определить следующие факторы. Например, пользователь должен определить типы данных, которые он должен извлекать из приложений и передавать приложениям. 52 Пользователь должен также рассмотреть, (1) как он хочет направлять сообщения между системными объектами; (2) как он должен преобразовывать данные от одного приложения для использования другими приложениями; и (3) должен ли он удалять некоторые данные из потока. Процесс конвертирования - средства доступа и конвертеры. Как отмечалось выше, другой важной функцией модели сообщения является импорт и экспорт данных из собственных форматов файлов любого приложения. Файлы, содержащие как символьные, так и двоичные данные в форматах приложений и платформно-специфических форматах, переводятся в описанную "каноническую" форму, где данные представлены как объекты Java. Ключевая цель в дизайне этой схемы состоит в том, чтобы максимизировать возможность многократного использования. Поэтому данное определение сообщения может быть сконфигурировано пользователем вместе с концептуальным "драйвером устройства". То есть два собственных формата файла, которые структурно представляют один и тот же формат данных, могут производить идентично структурированные канонические сообщения благодаря конфигурации с надлежащими драйверами."Драйвер устройства" фактически является набором объектов Java, называемых "средствами доступа" и "конвертерами", которые присоединены к соответствующим узлам в метаданных определения сообщения и глобальных метаданных. Полностью сконфигурированное определение сообщения образовано посредством конвертирования в последовательную форму объекта Java, который затем становится пакетным и готовым к использованию собственным устройством разбора формата файла и форматером для данного процесса конвертирования собственного формата файла и обеспечивает все преимущества самых последних средств кодирования набора символов и локализации, предоставляемых комплектом разработки Java (JDK). Все собственные символьные строки рассматриваются как массивы байт и конвертируются внутренне к Unicode для использования программами форматирования и разбора. Можно оценить, что версия 1.1.6 JDK поддерживает почти 100 различных кодировок символов и что модель сообщений согласно настоящему изобретению также поддерживает их с аналогичной логикой. Модель сообщений также стремится использовать наследование элементарных атрибутов, насколько этот возможно. Таким образом, подразумевается, что специфические для приложения данные имеют принятый по умолчанию порядок байт, кодировку и язык. Индивидуальные средства доступа могут переопределять любые эти параметры,но практически это не должно случаться слишком часто. 53 Средства доступа и конвертеры являются двухсторонними объектами. Они могут конвертировать собственные данные в объект Java,сохраненный в дереве сообщений, а также могут преобразовывать объект Java обратно к собственному представлению. В духе многократного использования один объект настоящего изобретения должен минимизировать общее количество классов конвертирования, которые должны быть написаны. Таким образом, процесс конвертирования, описанный здесь, может рассматриваться как двухсторонняя проблема, разметка/форматирование, с одной стороны, и конвертирование байт, с другой. Экземпляр класса средства доступа является объектом Java, который знает, как просеять "смесь символов" в собственном поле и изолировать определенные байты, которые некоторый конвертер должен произвести или конвертировать из объекта Java. Рассмотрим, например, случай, где поле данных с плавающей точкой отмечено с обеих сторон предопределенным байтом или последовательностью символов. В системе 100 они называются "маркерами". Специфический тип средства доступа (в данном случае средство доступа конечного маркера) знает, как перескочить начальный маркер и найти положение конечного маркера для изоляции 4 байт, которые фактически являются "сутью" данных с плавающей точкой. Конвертер байт с плавающей точкой, предварительно сконфигурированный в определении сообщения, производит из байт объект Java Float. В обратном направлении,средство доступа записывает начальный маркер,говорит, чтобы конвертер записал собственные байты, и затем средство доступа записывает конечный маркер. Одно из особых преимуществ этой схемы состоит в том, что должны быть написаны только горстка средств доступа и приблизительно две дюжины конвертеров. Так как средства доступа и конвертеры настоящего изобретения являются, по существу, однажды сконфигурированными объектами только для чтения, размер определения сообщения может сохраняться относительно малым благодаря совместному использованию объектов, где только возможно. Сборщик мусора Java легко удаляет выпуски тех, кто принадлежит объектам в этом случае. Некоторые средства доступа и конвертеры должны быть сконфигурированы с начальными установками, в то время как другие нет. Эти объекты упакованы как JavaBeans, с простыми диалогами свойств, где необходимо. В соответствии с предпочтительной реализацией изобретения следующая таблица формулирует средства доступа, поддерживаемые системой 100. При потребности в новых типах они могут быть легко добавлены к системе 100 без потребности в написании новых конвертеров. 54 Тип устройства доступа Фиксированной длины Конечного маркера Подразумеваемой длины Секции с ограничителем Объекта на основе синтаксиса Характеристики Поле устройства доступа всегда фиксированной длины. Эта фиксированная длина указывает либо полную длину поля, либо его длину минус любые маркеры. По существу, такой же, как и устройства доступа фиксированной длины, за исключением того, что другое совместимое с целым поле в данных содержит спецификатор длины. Эти индикаторы длины известны как "связанные" объекты и могут дополнительно помечаться как "временные" объекты, детали обоих из них более подробно описаны ниже. Поле заканчивается на конечном маркере. Длина поля неявна в конвертере - используется, главным образом, для двоичных форматов. Если содержащая секция использует схему с ограничителем, ограничитель может сигнализировать о конце объекта. Объект соответствует некоторому обычному выражению. Следует отметить, что каждое из средств доступа, описанных выше, является средством доступа к единичным элементам. В то же время также могут использоваться намного более простые средства доступа к секциям. Эти средства доступа к секциям имеют необязательные маркеры и могут также использовать схему с ограничителем. До некоторой степени включение такой схемы ограничителя зависит от успешного разбора содержащихся в ней элементов. Ограничители используют префиксную, инфиксную или постфиксную схему и фактически представляют те же самые маркерные элементы,используемые для ограничения полей. Средства доступа к таблицам расширяют средства доступа к секциям для работы со связанным единичным элементом, который указывает количество записей. Изначальное количество конвертеров,поддерживаемых системой 100, относительно мало, но основано на очень полном анализе коммерческих форматов файлов. Конвертеры согласно настоящему изобретению включают два основных типа: символьноориентированный конвертер или двоичный конвертер. Все символьные конвертеры наследуются от общего базового класса, который обеспечивает понятия выравнивания и дополняющих символов. Такие дополняющие символы могут быть определены как абсолютные байтовые символы или как символы Unicode, которые 55 соответствуют собственной кодировке. Символьные конвертеры согласно настоящему изобретению включают Тип Характеристики символьного конвертера Форматирует и разбирает данные в соответствии с "маской формата",образованной из определенной вjava.text.DecimalFormat. Маска имеет форму ,0.0, может указывать Десятичный такие особенности, как начальные или конечные маркеры, знаки минуса и т.д. Грамматика маски будет расширена при необходимости обеспечить любую пред- или пост-обработку, где грамматика недостаточна. То же, что и десятичный конвертер,Целый но без указания десятичных разрядов. Также поддерживаемое Java, дальДенежный нейшее усовершенствование десятичного конвертера. Использует спецификацию маски Даты/java.text.SimpleDateFormat. Этот форвремени мат весьма обширен и должен удовлетворять всем потребностям. Полагается на фиксированную длину,Обобщенной конечный маркер или секционный строки ограничитель для установки границ. Двоичные конвертеры наследуют заданный по умолчанию специфический для сообщения порядок байт, но могут индивидуально переопределяться через параметр конструктора. Эти двоичные конвертеры согласно настоящему изобретению включают Тип Характеристики двоичного конвертера Числа в дополнительном коде 8, 16,32 и 64 бит. Беззнаковые типы расширяются при необходимости до Знаковый/ следующего большего интегральнобеззнаковый го типа Java. Следует отметить, что двоичныйJava включает пакет произвольной точности в java.math для беззнаковых длинных слов (long).JNI может использоваться для неплавающей го, так же как и IntegerBits и Longточкой обычBits конвертеры, обеспеченные ной (float) и классами Float и Double. Следует двойной точотметить, что он поддерживается ности (double) только на платформах с собствен(спецификаным типом плавающей точки. ция 1985) Упакованный десятичный Конвертеры могут производить или получать больше чем один тип Java. Например, собственный конвертер с плавающей точкой может 56 также отображать, среди прочих, в типы Float,Double, Integer, Long или String. Все конвертеры реализуют собственный интерфейс конвертера,который определяется "Object load(Class,)" и"void store(Object)" функциональными возможностями. Однако фактический произведенный подкласс зависит от того, как другие интерфейсы конвертера реализованы объектом. Это, по существу, маркерные интерфейсы, которые не взаимодействуют с новыми методами. Например, DoubleConverter, IntegerConverter,StringConverter и т.д. могут использоваться в системе 100 без отклонения от духа и области рассмотрения настоящего изобретения. Такой инструмент конфигурации, как графический интерфейс пользователя (GUI), посредством самоанализа классов, может определить и представить соответствующий список конвертеров для использования в частном случае. Внутри методов загрузки и сохранения конвертер исследует, кто из поддерживаемых интерфейсов, реализуемых им, соответствует классу "экземпляра" объекта(Object) или полученному классу (Class). Тогда возвращаемый или обрабатываемый обобщенный объект (Object) имеет надлежащий подтип. Маркеры. Под маркерами можно подразумевать"смесь символов", используемую и для ограничителей полей, и для лексем индивидуальных единичных элементов. Все объекты либо секции или единичные элементы могут включать начальный маркер, конечный маркер или оба из них. В соответствии с предпочтительной реализацией изобретения имеются три основных формата маркеров. Два формата, известные как маркер фиксированного образца и маркер"strtok"-стиля, указывают либо байтовый образец, или Unicode строку, которая соответствует собственной кодировке символов. Включая набор символов, для которого найдены 0 или несколько вхождений, маркер "strtok"-стиля используется для индикации заполнения пробелом или двоичного заполнения. Третий формат,маркеров на основе ключа, имеет образец, в котором ключ обрабатываемого объекта заменяется в образце. Например, пара маркеров Х- и/-Х- стала бы Клиентами и /Клиентами,что будет использовано для разбора сообщенийXML-стиля, и значительно поможет при обнаружении необязательных единичных элементов. Необязательные параметры. Разбор и распознавание необязательных параметров является трудным процессом. Например, если входные данные определены в виде пяти необязательных строк любой длины и три строки успешно читаются, невозможно узнать,которая строка является которой. Необязательные единичные элементы сообщения, которые не обнаружены, будут установлены на 0. Далее следует набор условий, при которых необязательные единичные элементы могут быть распознаны в соответствии с настоящим изобретением. 57 Рассмотрим случай, в котором секция использует ограничители и найден ограничитель пустого поля. Например, пользователь узнал бы,что второй элемент отсутствует, если бы на входе было "АblеСhаrlеу" в инфиксной схеме. Другое условие, при котором могут быть распознаны необязательные единичные элементы,происходит, когда поля используют для самоидентификации маркер на основе ключа. В стиле C для параметров функций по умолчанию возникает еще одно условие, при котором разбор успешен, если все необязательные параметры находятся в конце списка и обнаружен конец секции. Обычно всякий раз, когда пользователь не в состоянии разобрать поле правильно и поле необязательно, он переходит к следующему полю и пробует снова, пока не достигнет конца секции. Секция с конечным маркером (или концом файла) подошла бы для этого случая. Разбор неуспешен, если в конце секции обязательным единичным элементам не было присвоено значение. Это не гарантирует правильных результатов, если формат последовательных единичных элементов неоднозначен. Значения по умолчанию работают поразному, в зависимости от того, является ли элемент секцией или единичным элементом. Метаданные сообщения единичного элемента содержат заданный по умолчанию объект. По умолчанию, если объект поддерживает интерфейс клонирования, объект клонируется из метаданных экземпляра сообщения. Если он не поддерживает этот интерфейс, то значение сохраняется в виде строки в метаданных наряду с ее классом и используется Java Reflection API для вызова конструктора объекта String для предоставления объекта сообщению. Для секций значением по умолчанию является связь с другим постоянно сохраненным определением сообщения. Секция верхнего уровня упомянутого определения сообщения будет "привита" к метаданным сообщения, и будет получено сообщение объединенной структуры. Связанные и временные единичные элементы. В некоторых случаях собственные данные самоописываются. Например, таблице может предшествовать счетчик ее рядов. Тем не менее,пользователи не хотели бы включать этот счетчик в произведенное заключительное каноническое сообщение, потому что он очевиден из длины массива Java, представляющего таблицу. В этом случае узел может быть произвольно отмечен временным. Он временно добавляется к сообщению и удаляется, как только таблица будет сформирована и добавлена. Таким образом, пользователь может конфигурировать определение сообщения с двумя различными драйверами с тем, чтобы производить одинаковые канонические сообщения. То есть если в одном случае размер таблицы был бы определен без индикатора счетчика, то целочисленное поле 58 не образовывалось бы в узле. В этом случае таблицы должны быть изоморфны, так что параметр должен быть временным. Продолжая вышеупомянутый пример,можно обратить внимание, что имеется неотъемлемая связь между счетчиком и таблицей. В результате, оба они будут отмечены как взаимосвязанные. Оба будут дополнительно содержаться в относительном и абсолютном пути другого объекта, плюс индикатор состояния в их средствах доступа, как отмечено ниже.REDEFINE-USER В случае переопределений провайдер предоставляет либо строку, либо интегральный дискриминант. Элемент провайдера должен появиться первым в направлении разбора, перед его использованием в обходе и конвертировании. В направлении форматирования провайдер сначала записывается с символом-заполнителем и впоследствии заполняется надлежащим значением. Следует отметить, что при работе провайдер счетчика должен использовать для него формат фиксированной длины. Условия проверки правильности и отношения. Определение сообщения имеет символызаполнители в его метаданных единичных элементов для списка условий проверки правильности и отношений между сообщениями. В соответствии с предпочтительной реализацией изобретения все условия проверки правильности выполняются над конвертированным сообщением только после конвертирования всего сообщения. Дизайн объекта, однако, позволяет, при желании, поэлементные условия проверки правильности. Имеется также символ-заполнитель для указания отношений между столбцами таблицы одного сообщения и столбцами другого. Это облегчает отображение значений и объединение. Способ, которым сообщение может быть создано без конвертирования и с конвертированием необработанных данных, показан на фиг. 13 и 14. Фиг. 13 иллюстрирует способ 1340 без конвертирования необработанных данных, который начинается в приложении 541. Пользователь создает пустое сообщение(например, "DocDef.createNewInsiance") в 1320,которое заполняется данными приложения посредством API определения сообщения 1330. Таким образом, создан экземпляр сообщения 1340. Экземпляр сообщения 1340 затем может пройти через API определения сообщения другого приложения 1350 с тем, чтобы послать сообщение этому приложению 1360. Когда возникает потребность в конвертировании необработанных данных, применяется способ, показанный на фиг. 14. В начале опре 59 деленные данные приложения 1410 получаются от приложения 1420. Пустое сообщение создается в 1430 и заполняется не только определенными данными приложения 1410, но также и конвертированной необработанной информацией. Определенные данные приложения 1410 посредством средств доступа и конвертеров 1440 посылаются экземпляру сообщения 1450,который также получает информацию, заполняемую в пустом документе в 1430. Например,это может быть выполнено посредствомAPI поддерживает оба следующих метода для создания сообщения:DocDef.createDocumentFromBytes Затем посредством других средств доступа и конвертеров 1460 сообщение может быть конвертировано в определенные данные другого приложения 1470 и получено этим приложением 1480. Относительно фиг. 15(а)-15(d) будут описаны выгоды от объекта сообщения согласно настоящему изобретению. Фиг. 15(а) иллюстрирует один способ 1510 создания сообщения без конвертирования необработанных данных приложения в соответствии с настоящим изобретением. Пустое сообщение создается приложением 1512 на первом шаге. Это выполняется посредством создания определения сообщения 512EmptyDocument(docname);"). API приложения 1514 соединяется с API определения сообщения 1516 с тем, чтобы заполнить сообщение при помощи API определения сообщения 1516. Затем могут применяться значения сообщения по умолчанию (например, "def.applyDocumentDefaultValues(docname)"), и таким образом, создается экземпляр сообщения 1518. Обратный способ 1520 показан на фиг. 15(b), где экземпляр сообщения 1522 посылается через API определения сообщения 1524, который соединен с API приложения 1526, и используется для заполнения значений полей. Сообщение затем посылается приложению 1528. Создание сообщений с конвертированием данных приложения является более сложным случаем. Как показано на фиг. 15(с), согласно настоящему изобретению способ 1530 преобразования сообщений от приложения 1532 до экземпляра сообщения 1538 начинается с сообщения, посылаемого от приложения 1532 конвертеру. API определения сообщения 1536 создает пустое сообщение, заполняет пустое сообщение данными приложения 1532 (то есть или из файла, или из байт) и добавляет конвертированную необработанную информацию из средств доступа и конвертеров согласно настоящему изобретению. Например:def.createDocumentFromBytes(docname.byte ) Обратный способ 1540 показан на фиг. 15(d), где экземпляр сообщения 1542 посылается через API определения сообщения 1544 для заполнения файла или массива байт 1546 данными от экземпляра сообщения 1532, а затем посылается приложению 1548. Например:def.storeDocumentToFile(filename) или,def.storeDocumentToBytes(byte ) Диаграммы классов для подобных процессов показаны на фиг. 16 и 17. В соответствии с другим важным аспектом настоящего изобретения система 100 включает распределенную систему. То есть пользователь может выполнять системные компоненты, которые составляют систему 100 на одной или нескольких физических машинах (то есть хостах), но все компоненты работают вместе как одно приложение. Каждый компонент системы 100 может распространяться среди всех поддерживаемых платформ. Агент-адаптеры 200 гибко расширяют это на составляющие приложения. Ключевые компоненты системы 100 (например, агентадаптеры 200 или интеграционный сервер 26) могут, таким образом, быть расположены совместно с приложениями, или иметь дистанционный доступ, или и то, и другое. Возможны многочисленные конфигурации развертывания - среда оптимизирована для баланса работоспособности, производительности и административных требований. Операторы. Следующая таблица описывает, в основном,все рассматриваемые в настоящее время системные операторы, которые пользователь может использовать для формирования выражений для определений сообщений, определений преобразования и определений фильтрации. Система 100 поддерживает следующие операторы. Оператор Описание Логическое "И" Логическое "ИЛИ" Логическое "НЕ" Присваивание Логическое "РАВНО" Логическое "НЕ РАВНО" Сложение Вычитание Умножение Деление Меньше Меньше или равно Больше Больше или равно

МПК / Метки

МПК: G06F 13/00

Метки: приложения, система, интеграционная, предприятия, распределенная, расширяемая

Код ссылки

<a href="https://eas.patents.su/30-3744-rasshiryaemaya-raspredelennaya-integracionnaya-sistema-prilozheniya-dlya-predpriyatiya.html" rel="bookmark" title="База патентов Евразийского Союза">Расширяемая распределенная интеграционная система приложения для предприятия</a>

Похожие патенты