В продолжение затронутой темы в данной статье будут рассмотрены вопросы координированного взаимодействия между компонентами САПР на уровне знаний и объектов для решения задачи динамического управления слабо связанными источниками информации.
ВведениеПроблема организации взаимодействия компонент очевидна: одна часть программного обеспечения САПР должна получать доступ к сервисным функциям, предоставляемым другой частью. Другое дело, что в каждом конкретном случае форма и механизм доступа могут быть разными. В одном случае, это может быть обмен знаниями, запрос данных или достижение согласованного решения посредством переговоров, в другом – вызовы локальных функций, передача сообщений между процессами, сетевые коммуникации.
Поэтому и усилия по решению проблемы взаимодействия компонент в распределенных гетерогенных системах предпринимаются в нескольких направлениях. Так, технология распределенного объектного программирования концентрирует усилия на описании стандартного механизма, с помощью которого одна часть программного обеспечения предоставляет свои сервисные функции другой, предоставляя программисту прозрачность механизмов доступа. Речь идет о таких стандартах и подходах к организации коммуникации как CORBA, DCOM, Inter-Language Unification (ILU) [4, 5].
Технология интеллектуальных агентов (ИА) уделяет основное внимание разработке соглашений по спецификации семантики взаимодействия на основе сервисных функций, предоставляемых агентами. Примером такого подхода являются спецификации языка взаимодействия агентов FIPA и язык запросов и обработки знаний (Knowledge Query and Manipulation Language – KQML) [6, 7]. А если добавить сюда усилия, направленные на разработку инженерных онтологий или формальных словарей для представления знаний о технических системах и процессе проектирования [8, 9], то получим тот базис, на котором можно строить взаимодействие в многокомпонентных САПР.
Базовые механизмы взаимодействия в многокомпонентных САПРМногокомпонентная САПР, как и другие компьютерные системы предприятия, должна обеспечивать кооперацию между компонентами, расширение функциональных возможностей и интеграцию в общую информационную среду. Она является структурированной системой и представляет собой совокупность процессов, как правило распределенных по различным компьютерным платформам, объединенным в сеть. При этом новые процессы должны сопрягаться с существующими носителями и обработчиками информации. До тех пор, пока взаимодействие сложных программных систем (например, взаимосвязь знаний в операциях assert, retract или распределение сервисных функций) остается предметом взаимных соглашений между программистами, кооперация будет ограничиваться простым набором программ, разработанных для взаимодействия друг с другом. Решение данной проблемы лежит в стандартизации механизмов взаимодействия программных компонент.
Основы технологии распределенных объектовПерспективным, с точки зрения сокращения влияния сложности САПР на ее разработку, сопровождение и использование, видится применение стандартов и соглашений распределенной вычислительной среды (Distributed Computing Environment – DCE). DCE основана на компонентной архитектуре, которая рассматривает каждый элемент системы (объект) в качестве повторно используемой программной компоненты. Инкапсуляция обеспечивается использованием стандартного интерфейса, который скрывает от пользователя язык или среду разработки компоненты. Тем самым объекты могут легко воспроизводиться и перемещаться по сети, создавая гибкие конфигурации.
Один из подходов к стандартизации взаимодействия компонент предлагает модель многокомпонентных объектов (Component Object Model – COM), которая определяет соглашения и обеспечивает сервисы описания, использования и коммуникации объектов. Этот стандарт позволяет двум приложениям взаимодействовать посредством объектного интерфейса, специфицированного на языке описания, который не зависит от языка реализации объекта. Распределенная COM (Distributed COM – DCOM) – это дальнейшее развитие модели, в которой термин «распределенная» подразумевает способность запуска клиентов и серверов на распределенных платформах Интернет или Интранет. DCOM работает так же как и COM: клиент запрашивает регистр, в котором находится информация о сервере, и вместо того, чтобы использовать локальный указатель, использует непосредственно IP адрес (например, 123.234.199.27) для доступа к серверу. Спецификация DCOM использует протокол объектного удаленного вызова процедур Object RPC. Он представляет собой адаптацию стандарта DCE, имеет ту же структуру пакета, но расширяет систему соглашений о взаимодействии клиент/сервер. Протоколы CN(CO) и DG(CL) используются над транспортным уровнем протоколов TCP или UDP соответственно (рис. 1,а).
Очевидным недостатком рассмотренной модели с точки зрения построения многокомпонентных САПР является отсутствие описания содержательного аспекта взаимодействия. Это обусловлено трудностями работы приложений в динамических распределенных средах и, как следствие, основная задача, которую преследуют стандарты в этой области заключается в том, чтобы обеспечить приложениям обмен на уровне структур данных и вызова удаленных методов. Однако компоненты САПР (агенты), в том смысле, как обсуждалось в статье [1], не сводятся только к структурам данных и операциям над ними. Поэтому указанные стандарты и протоколы могут рассматриваться лишь в качестве основы, на которой строится язык взаимодействия агентов, определяющий, в первую очередь, семантику взаимодействия.
KQML – язык запросов и обработки знанийДругая парадигма построения распределенных систем непосредственно строится на концепции агента и использовании языка взаимодействия между агентами для координации их деятельности. Примером такого подхода является спецификация языка запросов и обработки знаний KQML. Он основан на теории речевого взаимодействия (Speech-Act Theory), т.e. сообщение представляет собой исполняемую команду (performative), предусматривающую конкретное действие получателя [10]. Например, простое сообщение «сообщить (tell)» предполагает, что получатель должен верить представленным в теле сообщения фактам, тогда как, сообщение «спросить (ask)» предполагает ответ на присланный запрос.
KQML представляет собой структурированный язык взаимодействия агентов. Его можно рассматривать как двухуровневую структуру: на первом, содержательном уровне описывается содержание сообщения на языке представления агента, а на уровне сообщений или коммуникации описываются параметры сообщения. KQML может являться носителем любого языка представления, включая обыкновенные ASCII строки или бинарные коды. Это обеспечивается тем, что все реализации KQML игнорируют содержательную часть информации, исключая лишь признак ее завершения.
Синтаксис сообщения в семантике KQML включает команду, за которой следует набор слотов в формате: ключевое слово – значение. Параметры сообщения определяют характеристики низкого уровня коммуникации, такие как идентификаторы отправителя и получателя, идентификатор самого сообщения и задают характер взаимодействия с KQML агентом. Основной функцией коммуникационного уровня является идентификация протокола передачи сообщения и поддержка процесса выполнения задания, которое связывается отправителем с содержательной частью сообщения.
KQML используется в качестве языка взаимодействия в различных многоагентных системах и средах для их программирования, таких как Agent-K, LALO, Java(tm) Agent Template (JATLite) [11-13].
Структура взаимодействия в первых двух системах близка. Обе используют концепцию агентно-ориентированного программирования, основанную на ментальных категориях [14], и механизм правил обязательств агентов для описания стратегии их поведения при получении сообщений, записанных на языке KQML. Последние доставляются адресату непосредственно транспортным протоколом TCP/IP (рuc. 1,б).
JATLite использует аналогичную схему организации взаимодействия, но без определения какой-либо теории агентов, т.е. в данном случае уровень описания стратегий взаимодействия отсутствует.
Учитывая, что запросы и интересы выражаются в KQML формальным декларативным языком, значение терминов не зависит от конкретных программ и, следовательно, может разделяться программами с различной реализацией контекста и представлением знаний. Таким образом, взаимодействие описывается на высоком уровне, тогда как детали посылки сообщений, связанные с различием операционных сред и алгоритмов принятия решений, оказываются скрытыми. Вместе с тем, в системах, состоящих из различных приложений, таких как САПР, использование языка KQML для спецификации взаимодействия только на уровне знаний не в силах полностью решить проблемы интеграции, хотя бы по той простой причине, что многие компоненты не являются интеллектуальными и не поддерживают этот уровень взаимодействия.
Модель взаимодействия агентов в многокомпонентной САПРНа текущем этапе разработки среды DESO было признано целесообразным использовать интеграцию концепций агентов и распределенных объектов на основе многоуровневой структуры взаимодействия агентов. Каждый уровень определяет управляющий интерфейс между различными уровнями абстракции, механизмами и протоколами (рис. 2).
Разделяемая онтология обеспечивает общий словарь для решения прикладных задач проектирования, определяет семантику сообщений и отвечает за интерпретацию контекста сообщения. Его расссмотрение выходит за рамки данной статьи.
Протокол взаимодействия агентов определяет стратегию высокого уровня и структуру переговоров между агентами. В динамическом и кооперативном контексте многокомпонентных САПР ее можно характеризовать как комбинацию взаимодействий типа «запрос/ответ» и «обмен знаниями (или информирование)». На этом уровне семантика сообщений связывается с действиями, предпринимаемыми агентом:
Правило обязательства определяет действия агента как реакцию на сообщение «ask-one», которое запускает на выполнение предикат WorkingArea и возвращает результат в формате KQML агенту источнику сообщения.
Язык взаимодействия агентов определяет семантику взаимодействия независимо от приложения, определяет тип и содержание запроса. Этот уровень преобразует соответствующую часть правил, связанную с генерацией агентом сообщений в выражения языка KQML и обратно. Приведем в качестве примера запрос о величине рабочей зоны конкретного станка из типового диалога агентов в DESO:
В приведенном сообщении ask-one – это KQML команда, содержание сообщения – working_ area(Machine, X), а предполагаемая онтология имеет идентификатор MachineDBManager.
Протокол взаимодействия объектов определяет стандартные механизмы, которые используются для логического взаимодействия между компонентами. В DESO механизмы OLEnterprise выполняют посылку выражений KQML в качестве семантических событий (вызовы сервера ActiveX). ActiveX обеспечивает функции совместимости, используя Object Data Base Connectivity (ODBC), Object Request Broker (ORB), Internet Inter-ORB Protocol (IIOP), и Object Remote Procedure Calls (ORPC). При этом Interface Definition Language (IDL) используется для описания отображения команд и параметров KQML и DCOM. Аналогичный подход, основанный на интеграции KQML и CORBA в архитектуре COBALT, представлен в работе [15].
Транспортный протокол представляет модель и механизм физического взаимодействия. Механизмы OLEnterprise используют протокольный стек Transmission Control Protocol/Internet Protocol (TCP/IP) для реализации сообщений низкого уровня.
Организация взаимодействия между агентами DESO на основе механизмов OLEnterprise
Рассмотрим некоторые особенности реализации рассмотренной модели. В качестве платформы для реализации прототипа DESO были использованы средства OLEnterprise, обеспечивающие динамический OLE доступ к распределенным объектам [16]. OLEnterprise основан на спецификации DCOM, тем самым обеспечивая полную интеграцию со средствами разработки и приложениями Windows. OLE компонент может выполняться в качестве in-process или out-of-process по отношению к клиенту. В первом случае он реализуется в виде файла библиотеки динамического линкирования (Dynamic Link Library – DLL) и выполняется в процессе клиента. Во втором случае компонент выполняется в виде исполняемого файла и размещается в своем адресном пространстве.
OLEnterprise включает 3 компоненты: Object Explorer (броузер локальных и удаленных объектов), Object Agent (локальный сервер OLE Аutomation) и Object Factory (удаленный контроллер OLE Аutomation). Эти компоненты интегрированы в среде DESO и позволяют приложениям клиентам использовать объекты OLE Automation и объекты RPC сервера независимо от их расположения в сети. Кроме того, гибкий механизм управления сервисами обеспечивает прозрачность размещения и балансировку загрузки серверов, авторизацию пользователей и защиту данных. Общая схема обработки сообщений агентов DESO на базе OLEnterprise показана на рис. 3.
Поясним назначение и функционирование каждого элемента приведенной схемы. Object Agent – это in-process сервер OLE Automation, исполняемый как DLL. Object Agent располагается на машине клиента и обеспечивает динамический прозрачный доступ к любым объектам OLE или RPC. Он определяет механизм посылки сообщений локальных агентов-клиентов DESO, реализованных как Automation Controller [3]. Для агента DESO он выглядит так же как и любой другой сервер OLE Automation. Но он способен перенаправлять запрос агента удаленному серверу. Если удаленный объект является объектом OLE, то запрос адресуется Object Factory, которая воспроизводит запрос ActiveX на удаленной машине. Если удаленный объект является объектом OLEnterprise, то Object Agent автоматически преобразует запрос в RPC запрос и направляет его соответствующему серверу.
Object Factory – удаленный OLE controller, обеспечивает доставку распределенных сервисов OLE Аutomation (менеджер удаленных OLE запросов). Object Factory располагается вместе с агентами-серверами DESO, реализованными как Automation Server, и отвечает за их активизацию и формирование запросов от лица удаленных агентов-клиентов. Object Factory является одновременно RPC сервером и клиентом OLE Automation. Он выполняет функции виртуального (proxy) клиента OLE Automation, представляя удаленного агента-клиента.
Object Explorer содержит три основные функциональные компоненты: броузер для просмотра локальных и удаленных регистров, механизм экспортирования для выбора серверов OLE Automation для удаленного доступа и механизм импортирования для локальной регистрации удаленных серверов OLE Automation. Он используется для инициализации агентов DESO. На сервере генерирование и регистрация сервера OLE Automation в регистре производится с использованием стандартных утилит OLE.
Архитектура многокомпонентной САПРВ заключение рассмотрим общую концепцию архитектуры многокомпонентной САПР, вписывающую концепцию агентов в общую архитектуру клиент-сервер, построенную на основе концепции распределенных объектов (рис. 4). Серым цветом выделены компоненты среды DESO.
Взаимодействие пользователя с распределенными компонентами САПР существенно упрощается при использовании Интернет/Интранет решений для разработки пользовательского интерфейса. В этом случае компоненты САПР (клиенты) могут быть интегрированы посредством так называемой «шины представительского уровня». Ее цель – позволить компонентам клиентам (агенты DESO, агенты-Java, plug-ins и ActiveX, ORBs) разделять модели взаимодействия распределенных объектов. В качестве реализации этого уровня может быть использован, например, Netscape’s LiveConnect [17].
Агенты могут использовать структуру коммуникации «каждый-с-каждым» (peer-to-peer или A2A). Так, агенты DESO могут непосредственно использовать протокол А2А, который выполняется на стандартных протоколах, таких как сокеты. С другой стороны, использование протоколов взаимодействия объектов (механизмов OLEnterprise) обеспечивает взаимодействия без точного указания (знания клиентом) места расположения вызываемого метода. В системах этого типа существует особый сервер, склеивающий клиентов и серверы. В DCOM – это Service Control Manager (SCM), в CORBA – это брокер объектов, поддерживающие удаленную активацию объектов (с использованием интерфейса IActivation). В мультиагентной системе сервер имен агентов (Agent Name Server – ANS или Agent Message Router – AMR в JATLite) выполняет те же функции, преобразуя логическое имя агента в его адрес, соответствующий физическому расположению. ANS поддерживает регистр агентов и услуг, за которые он отвечает.
Реализация компонент САПР может быть выполнена в виде любой комбинации Java аплетов (applets), встраиваемых фрагментов (plug-ins), компонент ActiveX, и компонент сервера, поддерживающих IIOP. При этом стандартные протоколы, типа HTTP, RMI и JDBC, дополняются IIOP связи с DCOM сервером. Интерфейсы выставляются ORB путем компиляции их спецификации, написанной на IDL, что обеспечивает возможность подключения внешних приложений. Кроме того, OLEnterprise включает шлюз OLE Gateway, который эффективно расширяет возможности OLE, поддерживая механизмы RPC и CORBA и обеспечивая интеграцию Windows компонент DESO с компонентами Unix и других платформ.
Для поддержки обработки описанной выше структуры сообщений между подсистемами могут быть введены специальные коммуникационные агенты (фасилитаторы). Использование фасилитаторов становится особенно важным в условиях интеграции новых компонент САПР с существующими, которые не имеют необходимой степени гибкости в преобразовании входных/выходных форматов.
ЗаключениеТрадиционные подходы к интеграции и взаимодействию средств проектирования основываются на стандартизированных структурах данных и единой модели проектирования, и требуют определенных соглашений между проектировщиками. Реализация архитектуры гетерогенных ИА на уровне системы обеспечивает унифицированный механизм коммуникации между компонентами DESO. Подход, развиваемый в DESO и представленный в данной статье, отличается следующими моментами. Во-первых, данные и модели инкапсулированы в каждом средстве, а не стандартизированы и унифицированы. Это обеспечивает возможность использования каждым средством наиболее подходящего внутреннего представления проблемы. Во-вторых, агенты используются для поддержки взаимодействия между компонентами путем преобразования внутренних представлений на язык взаимодействия, который описывает лишь разделяемую часть общих знаний. Будучи обеспечена средствами спецификации разделяемого контекста, среда DESO позволяет взаимодействующим системам обмениваться данными без предварительных соглашений по форматам и обеспечивать маршрутизацию и прием с уведомлением на основе содержания сообщения, а не просто синтаксических шаблонов.
В-третьих, использование стандартов и соглашений взаимодействия компонент в распределенных системах открывает возможность интеграции САПР с другими системами, поддерживающими концепции как агентов так и объектов. Использование JAVA для программирования агентов также не исключает возможность использования стандартов типа CORBA или DCOM. Пример их совместимости – в уже разработанных компилляторах языка определения интерфейса IDL для Java. Таким образом принципиальных границ для интеграции JATLite с объектами CORBA или DCOM не существует, хотя авторам и не известны реализации на момент написания статьи.
Описанная работа проводилась в рамках проекта по гранту Государственного Комитета Российской Федерации по науке и технологиям №№ 142, 05.04.1233н, 037.02.236.132/1-96, 037.02.298.5/1-98. Проведенные эксперименты не привели бы к успеху без участия группы исследователей и программистов лаборатории интегрированных систем автоматизации Санкт-Петербургского института информатики и автоматизации РАН.
Литература1. Смирнов А.В., Шереметов Л.Б. Многоагентная технология проектирования сложных систем. Автоматизация проектирования, №№ 3 – 1998, 1 – 1999
2. Smirnov, A.V., Sheremetov, L.B., Romanov, G.V. & Turbin, P.A. Multi-Paradigm Approach to Cooperative Decision Making. In Proc. of the II International Conference on Concurrent Engineering: A Global Perspective. McLean, Virginia, August 23-25, Concurrent Technology Corporation, 1995. pp. 215 – 222.
3. Sheremetov, L.B. & Smirnov, A.V. A Model of Distributed Constraint Satisfaction Problem and an Algorithm for Configuration Design. Computacion y Sistemas, 1(2): 91-100, 1997.
4. CORBA 2.0 Specification, Object Management Group, ptc/96-03-04, 1996.
5. Distributed Component Object Model protocol DCOM/1.0. Network Working Group, Internet-Draft, 1996.
6. FIPA7412, Draft 1.0, document of the Foundation for Intelligent Physical Agents (FIPA), 1997.
7. Finin, T., Labrou, Y., & Mayfield, J. KQML as an agent communication language, In Jeff Bradshaw (Ed.), Software Agents, MIT Press, 1995.
8. Bradshaw, J. M., Holm, P. D., Boose, J. H., Skuce, D., & Lethbridge, T. C. Sharable ontologies as a basis for communication and collaboration in conceptual modeling. In Proceedings of the Seventh Knowledge Acquisition for Knowledge-Based Systems Workshop, Banff, Alberta, Canada, 1992, pp. 3.1 – 3.25.
9. Patil, R.S., Fikes, R.E., Patel-Schneider, P.F., etc., The DARPA Knowledge Sharing Effort: Progress Report. In Huhns, M.N. & Singh, M.P. (Eds.), Readings in Agents, Morgan Kaufmann Publishers, Inc. 1998, pp. 243 – 254.
10. Cohen P.R. & Levesque H.J. Communicative actions for artificial agents. In Proceedings of the First International Conference on Multi-agent Systems (ICMAS’95), San Francisco, CA, 1995.
11. Davies, W.H.E. & Edwards, P. Agent-K: An Integration of AOP and KQML. AUCS/TR9406, Univ. of Aberdeen, Scotland, UK, AB92UE, 1994.
12. Gauvin, D. Un environnement de programmation oriente agent. Dans Troisiemes journees francophones sur l’intelligence artificielle distribuee et les systemes multiagents. St-Baldoph, Savoie, France, 15-17 mars 1995.
13. Frost, H.R. & Cutkosky, M.R. Design for Manufacturability via Agent Interaction. In 1996 ASME Design for Manufacturing Conf., Irvine, CA, Aug., 1996, pp. 18 – 22.
14. Shoham, Y. Agent-oriented Programming. Artificial Intelligence 60(1):51-93. 1993.
15. Benech, D., Desprats, T. & Raynaud, Y. A KQML-CORBA Based Architecture for the Communication of Intelligent Agents in Cooperative Service and Network Management. In Proc. of the First IFIP/IEEE International Conference on Management of Multimedia Networks and Services ‘97, July 8-10, Montreal, Canada. 1997.
16. Koulinitch, A.S. & Sheremetov, L.B. Agents coordination and communication in distributed configuration design. In Primer Encuentro Nacional de Computacion, Taller de Sistemas Distribuidos y Paralelos, Queretaro, Mexico, Sept., 12-15, 1997, pp. 92 – 99.
17. Bradshaw, J. M. KAoS: An open agent architecture supporting reuse, interoperability, and extensibility. B. R. Gaines & M. Musen (Ed.), Proceedings of the Tenth Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, Banff, Alberta, Canada, 2 (pp. 48:1 – 48:20).
commit([«ask-one», content(working_area(Component, Min, Max))],S,kqml(Now, [reply, receiver(S sender(R),content(working_area(Component, Min, Max)), reply-with(Origin), language(prolog)]))
 |
| Рис. 3. Архитектура взаимодействия агентов DESO с использованием механизмов OLEnterprise |
 |
| Рис. 4. Архитектура многокомпонентной САПР |