Лекции - Корпоративные информационные системы и технологии
Подождите немного. Документ загружается.
посылки сообщений локальных агентов-клиентов DESO, реализованных как
Automation Controller [3]. Для агента DESO он выглядит так же как и любой другой
Рис. 3. Архитектура взаимодействия агентов DESO с использованием механизмов
OLEnterprise
сервер 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.
Рис. 4. Архитектура многокомпонентной САПР
Взаимодействие пользователя с распределенными компонентами САПР существенно
упрощается при использовании Интернет/Интранет решений для разработки
пользовательского интерфейса. В этом случае компоненты САПР (клиенты) могут быть
интегрированы посредством так называемой «шины представительского уровня». Ее
цель – позволить компонентам клиентам (агенты 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 и других платформ.
Для поддержки обработки описанной выше структуры сообщений между
подсистемами могут быть введены специальные коммуникационные агенты
(фасилитаторы). Использование фасилитаторов становится особенно важным в
условиях интеграции новых компонент САПР с существующими, которые не имеют
необходимой степени гибкости в преобразовании входных/выходных форматов.
Литература
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).
8 Технологии интеграции современных сервисов
в корпоративной сети - SOA.
8.4 Технологии SOA. Общие характеристики и
проблеммы. GRID- среда.
Каждый предшествующий век начинался с очередной технической революции:
XIX век — с появления паровых машин, XX-й — с электричества и двигателей
внутреннего сгорания. Лет через пятьдесят потомки скажут с какой революции
начался XXI век. Пока же можно предположить, что среди претендентов на
первенство есть еще не нашедшие своего точного названия системные
изменения в компьютинге. Возможно, в этом ряду могут оказаться и
Архитектуры, ориентированные на сервис.
Увы, современники спешат с оценками. Часто получается так, что, к
сожалению, компьютерные аналитики и пресса берут на себя примерно ту же
самую функцию, что и дома высокой моды. Их объединяет общее стремление
пропагандировать то, что еще пока никому не нужно — и, быть может, не
станет нужным никогда. К тому же, любая мода — и компьютерная мода не
исключение — обязательно должна быть не просто новой, а радикально новой.
Старая мода нужна не больше, чем прогноз погоды на вчера.
Вокруг новинок создается излишняя шумиха, мешающая отделить мнимые
новации от подлинных ценностей. К числу последних вполне можно отнести
хиты нынешнего сезона: «Архитектура, ориентированная на сервисы» (Service
Oriented Architecture — SOA) и «Сервисная шина предприятия» (Enterprise
Service Bus — ESB). Это явления более чем серьезные, хотя есть и скептические
мнения. Так, заметный резонанс получила статья инженера из американского
отделения компании Software AG Майкла Чампиона [1], который язвительно
называет хвалу SOA и ESB «пропагандой очередного сдвига парадигмы» и
«десятой революцией из двух предсказанных». Под влиянием SOA может
измениться, в том числе, и мир разработки приложений [2]. Чем же
обусловлены грядущие изменения?
8.4.1 Мнения аналитиков
Gartner Group утверждает, что следующие годы должны стать переломным в
истории индустрии программного обеспечения. Заголовки предсказаний Gartner
звучат так: «SOA изменяет программное обеспечение», «SOA вступает в эпоху
Web-сервисов», «SOA взбудоражит рынок серверов приложений», «Сервисная
шина предприятия вышла на свет».
IDC опубликовала отчет «Сервисная шина предприятия революционизирует
информационные технологии», где в качестве базиса для этого
технологического решения фигурирует, SOA. Менее известная аналитическая
компания ZapThink также утверждает, что SOA станет в ближайшие годы
основой для ориентированной на процессы интеграции приложений, а объем
этого сегмента рынка всего за несколько лет вырастет до 8-10 млрд. долл.
Схожие заявления о перспективности SOA можно найти и у Giga Group, Meta
Group и др. Однако надо признать, что все более или менее именитые аналитики
по части ИТ уступили пальму первенства небольшой компании из Сан-
Франциско Stencil Group.
Специалисты Stencil одними из первых смогли не просто оценить
перспективность SOA, но и показать глубинную природу изменений,
происходящих в архитектуре корпоративных систем [3]. Согласно их трактовке,
появление SOA есть следствие закономерного эволюционного процесса,
который наблюдается в течение последних 40-50 лет (таблица 8.1).
Таблица 8.1. Три поколения корпоративных систем по классификации
Stencil Group
Архитектура SOA, как считают в Stencil, представляет собой новый и вполне
закономерный этап эволюции корпоративных систем. Предпринятая попытка
классификации интересна и полезна, но стоит учесть, что она несколько
поверхностна. В ней все сводится лишь к технической стороне, к тому, что
обычно называют информационной системой; между тем, она, в свою очередь,
является подсистемой всей корпоративной системы в целом. Информационная
система, как совокупность аппаратных и программных средств,
эволюционирует не автономно; она развивается в сложной взаимосвязи с
развитием всего корпоративного организма. Поэтому первые четыре строки,
непосредственно относящиеся к технологиям, можно принять без всякой
критики; что же касается «пользователей» и «значения для бизнеса», то и c этой
частью можно согласиться, но с определенной натяжкой. Дело в том, что при
переходе от мэйнфремов к клиент-серверным конфигурациям и далее к SOA
изменяется функциональность, пересматриваются представления об
информации и данных, а это явления более глубокие, чем изменения в
аппаратной или программной архитектуре.
Соответственно архитектуре меняются и средства разработки. Еще в 1998 году
по используемым средствам разработки совокупность новых проектов делилась
поровну [12]: 50% приходилось на долю технологии Microsoft DNA и 50% — на
долю всех остальных. Язык Java обладал долей, составляющей всего лишь
около 1%. В 2005 году средства разработки, связанные с Java, отнимут чуть
менее 40% рынка и станут самым большим сегментом. Оставшуюся часть
разделят примерно поровну средства Microsoft .Net и традиционные
программные технологии, причем на Microsoft DNA придется всего несколько
процентов. Соответственной этому будет и динамика занятости.
8.4.2 Попытки определения SOA
Неопределенность, наблюдаемая сегодня в представлениях о SOA, хорошо
знакома — явный «эффект дежавю». Когда в конце 90-х заговорили о Web-
сервисах, на читателей обрушился поток противоречивых определений: на
сайте компании Systinet справедливо утверждается, что, если попросить
помощи у пяти специалистов, то можно получить, как минимум, шесть
определений [4].
Столь же противоречиво определяют сегодня и SOA.
I. Stencil Group. Архитектура, ориентированная на сервисы имеет четыре
основные характеристики.
1. Является распределенной. Функциональные элементы приложений могут
быть распределены по множеству вычислительных систем и способны к
взаимодействию с использованием локальных или глобальных сетей. В
частности, Web-сервисы позволяют использовать существующие
протоколы, например, HTTP.
2. Строится с использованием слабосвязанных интерфейсов. Обычно
приложения проектируются в расчете на жесткую связь всех элементов.
Как следствие, система должна иметь целостный проект, его изменения в
процессе эксплуатации затруднительны. Работу компонентов в
слабосвязанных системах проще координировать, системы проще
реконфигурировать.
3. Базируется на общепринятых отраслевых стандартах.
4. Проектируется с ориентацией на процессы (process-centric) с
использованием сервисов, каждый из которых ориентирован на решение
отдельных задач (task-centric).
II. Gartner Group. В Gartner видят в качестве основной черты SOA деление на два
или более уровня [5]. Обращенный к пользователю презентационный уровень
отделен от внутреннего, где реализуется бизнес-логика. Последний создается из
крупных блоков (coarse-grained chunk), которые обеспечивают сервис
клиентским программам презентационного уровня. В логический уровень могут
включаться компоненты управления бизнес-процессами (business process
management — BPM). Практически, как считают аналитики этой компании, SOA
можно реализовать, в том числе, многозвенной клиент-серверной архитектурой,
но не двухуровневой архитектурой с толстым клиентом, который совмещает как
логику, так и презентацию.
III. International Data Corp. Аналитики IDC [6] определяют SOA как архитектуру,
предназначенную для свободного размещения функциональных модулей,
каждый из которых способен выполнять определенные действия. Эти модули
представляют собой описывающие сами себя программные компоненты,
достижимые через сеть. Модули публикуют свои интерфейсы таким образом,
что их использование не требует знания использованных в них решений и
технологий; их удобно воспринимать как черный ящик. SOA можно
реализовать и без использования Web-сервисов, однако сервисы
рассматриваются в качестве основного средства для создания подобной
архитектуры.
IV. Barry & Associates. Данная консалтинговая компания определяет SOA как набор
взаимодействующих между собой модулей [7]. Модули могут просто
обмениваться между собой данными или каким-то образом координировать
свои действия. Архитектура, ориентированная на сервисы, не представляет
собой ничего нового, считают здесь. Ее первыми примерами стали брокеры
объектных запросов, основанные на спецификации CORBA.
V. В компании ThoughtWorks утверждают: SOA представляет собой набор
сервисов, которые совместно образуют систему, призванную заменить
монолитные корпоративные приложения типа ERP [8]. Примерно такого же
мнения придерживается обозреватель журнала EAI Майкл Паллос, считающий,
что SOA представляет собой набор модулей для обеспечения бизнес-процессов
[9]. Дон Редер из компании Iona Technologies соглашается с таким мнением,
отмечая, что SOA предлагает методологию и набор средств интеграции
приложений [10].
Обобщая эти и многие другие определения SOA, можно согласиться с Майклом
Чампионом [1]: «И все же, мне кажется, за всей этой шумихой скрывается
мощная идея, которая еще не вполне точно обозначена; она и называется
сервисами». Эта идея размыта, поскольку пока не поддержана прозрачной и
общепринятой моделью или набором моделей, подобных семиуровневой
модели открытых систем.
Не находя общего языка, авторы в своих определениях под SOA понимают
близкие, но все же разные вещи. Одни рассматривают SOA как своего рода
механизм, создающий коммуникационную среду для модулей, реализующих
прикладную бизнес-логику. Примерно в этом ключе высказывается Адам
Босуорт, вице-президент компании BEA Systems [11]. В его представлении
посредством сервисов вычислительная система преобразуется в своего рода
коммуникационную систему для снабжения информацией; она превращается в
сервис сродни водопроводу. Стоит обратить внимание на близость взглядов
Босуорта с прогнозами Stencil Group относительно будущего баз данных.
Различие между ними заключается в том, что Босуорт предлагает их прямую
транспортировку в потоках данных вместо накапливания данных в базах.
Подобный коммуникационный взгляд на SOA можно назвать «взглядом снизу».
Но есть другой, более системный взгляд, «взгляд сверху» [8-10]. Прикладные
модули, получающие данные или информацию посредством сервисов, сами в
свою очередь являются сервисами, которые необходимо каким-то образом
связать в одну систему.
8.4.3 SOA и Web-сервисы
Архитектура SOA широко заявила о себе, став логическим продолжением
технологий Web-сервисов. Однако способы реализации сервисов могут быть
различными. В общем случае любая архитектура, ориентированная на сервисы,
обязательно содержит три компонента: поставщика сервиса, потребителя
сервиса и брокера (рис. 8.1).
Рис. 8.1. Архитектура, ориентированная на сервисы
Поставщик сервиса регистрирует его у некоторого брокера, потребитель там же
его обнаруживает, после чего между ними устанавливается связь в соответствии
с контрактом и осуществляется требуемое действие. Для создания SOA
необходимы три основных типа соглашений:
• транспортное, определяющее форматы и протоколы;