4.3. Реализация взаимодействия программных агентов в системах класса srm

В электронной коммерции часто приходится иметь дело с несколькими клиентами или партнёрами по бизнесу. Это поставщики, службы доставки грузов в регионы, платёжные системы, розничные и оптовые покупатели (рис.4.9). При обслуживании заказов довольно значительная часть времени уходит на различные согласования и переговоры (в частности, на выяснение наличия и резервирование товара у поставщика).

При поступлении заказа в интернет-магазин делается запрос поставщику на отгрузку необходимого товара. Аналогичный запрос может быть одновременно послан еще нескольким поставщикам. Ответы могут быть различными. Так, поставщики могут подтвердить заказ, отказать или послать контрпредложение (предложить аналогичный товар или скорректировать сроки). После подтверждения заказа в процессе общения с покупателем, уточняется время и место доставки.

Со временем о каждом поставщике складывается некое представление: он «надёжен», «ненадёжен» или «непредсказуем».

Аналогичную модель можно использовать и во взаимодействии двух программных агентов – участников бизнес-процесса. В результате у агента фирмы (A) складывается представление о конкретном поставщике (агент B) (рис. 4.10).

Обозначим ответы агента B: “Ag”– согласен, “DAg”– несогласен, “Neg”– переговорить (или контрпредложение). Обозначим «мнения» агента А об агенте B. Пусть: “Bel” – уверен, “Pl” – полагает, “DBt” – сомневается, “DBel” – не верит. Пусть p – некое предложение, например «Обеспечить поставку лыж размера 170 см по закупочной цене 100$ в 3 дня».

Тогда возможны следующие 12 вариантов сообщений:

Bel(A, p, Ag(B)) – агент A уверен, что агент B согласится на предложение p;

Bel(A,p,DAg(B)) – агент A уверен, что агент B не согласится на предложение p;

Bel(A, p, Neg(B)) – агент A уверен, что агент B переговорит предложение p;

Pl(A, p, Ag(B)) – агент A полагает, что агент B согласится на предложение p;

Pl(A,p,DAg(B)) – агент A полагает, что агент B не согласится на предложение p;

Pl(A, p, Neg(B)) – агент A полагает, что агент B переговорит предложение p;

Dbt(A,p,Ag(B))– агент A сомневается, что агент B согласится на предложение p;

Dbt(A,p,DAg(B)) – агент A сомневается, что агент B не согласится на предложение p;

Dbt(A,p,Neg(B))– агент A сомневается, что агент B переговорит предложение p;

Dbel(A,p,Ag(B)) – агент A не верит, что агент B согласится на предложение p;

Dbel(A,p,DAg(B)) – агент A не верит, что агент B не согласится на предложение p;

Dbel(A,p,Neg(B)) – агент A не верит, что агент B переговорит предложение p.

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

На рис.4.11 обозначено: Р1..Р3 – розничные покупатели, Ф1…Ф3 – фирмы продавцы, Д1…Д3 – службы доставки в регионы, П1….П3 – поставщики, М1…М3 - производители. Из схемы видно, что розничный покупатель может использовать схему отношений с фирмами-продавцами, фирмы-продавцы – со службами доставки и с поставщиками, а поставщики с производителями.

Каждое из этих отношений можно рассмотреть в рамках парадигмы клиент-сервер, где под клиентом подразумевается агент, совершающий запрос. Например, клиентом является интернет-магазин, отправляющий заказ на перевозку товаров из пункта “А” в пункт “Б”. Сервер, в данном случае, транспортная компания, должен обработать этот запрос и отправить ответ в установленной форме. Согласен ли безусловно сервер обслужить клиента, выполнив его запрос, либо он отказывается от заказа, либо необходимо дальнейшее согласование условий выполнения заказа (при этом можно послать свои условия клиенту).

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

На рис.4.12. введены следующие обозначения:

a

b

– связь реального и виртуального агента через GUI или интерфейс БД,

с

– миграция агента посредника от агента-клиента к агенту сервера и обратно,

– отправка сообщений от клиента к серверу и обратно.

Римскими цифрами I и II обозначены два способа взаимодействия клиента и сервера (с посредником и без).

В качестве клиента (рис. 4.11) здесь могут выступать:

розничные покупатели (во взаимоотношениях «покупатель – интернет-магазин»), например, когда покупатель делает заказ в интернет-магазине;

фирма-продавец (во взаимоотношениях «фирма-продавец – фирма-поставщик» или «фирма-продавец – транспортная компания»), например когда фирма-продавец делает заказ на поставку товара или заявку в транспортную компанию на доставку груза из пункта А в пункт В;

фирма-поставщик (во взаимоотношениях «фирма-поставщик – фирма-производитель» и «фирма-поставщик – транспортная компания»), когда поставщик делает заявку на производство необходимого товара, или поставщик заказывает доставку необходимого товара;

фирма-производитель (во взаимоотношении «фирма-производитель – транспортная компания»), когда производитель заказывает транспортировку сырья.

Соответственно, в качестве сервера в этих взаимоотношениях выступают: фирма-продавец, фирма-поставщик, фирма-производитель и транспортная компания. Кроме того, фирма производитель и транспортная компания также могут вступать в различные иные взаимоотношения, например со своими поставщиками. Таким образом, транзитивное замыкание данного отношения приведёт к вовлечению в наше рассмотрение практически всех фирм, присутствующих на рынке и связанных с данной отраслью.

На рис. 4.12 показаны два возможных типа взаимодействий: с использованием агента-посредника (случай I) и без него (случай II). Применение агента-посредника целесообразно тогда, когда предполагается длительное согласование условий контракта на стороне сервера. Использование посредника также эффективно, если клиент имеет плохой канал связи с серверами, а запрос ведётся сразу по нескольким серверам. Так как большинство агентов в рамках данной схемы выступают в обоих качествах (как в качестве клиента, так и в качестве сервера), представляется разумным разработать универсальный модуль, инкапсулирующий как функциональность клиента, так и сервера. Исключительное положение в рамках бизнес-процесса наблюдается лишь у веб-покупателя, для которого целесообразно разработать собственный веб-клиент.

Рис 4.13. Архитектура RM-системы.

На уровне протоколов архитектура системы в самом общем виде показана на рис 4.13. Предлагаемая инфраструктура взаимодействий основывается на унифицированном механизме удалённых коммуникаций с использованием единых протоколов взаимодействия высокого уровня. В качестве таковых могут быть использованы ACL-протоколы для контрактных сетей [140].

4.4 RM-система управления взаимодействием с поставщиками и заказчиками.

Основное направление разработки такой системы было представлено в первой главе данной диссертации, здесь мы дадим более подробную детализацию реализованной системы. Система разработана на платформе Java c использованием библиотеки агенно-ориентированной разработки Beegent. Основными модулями системы являются:

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

• агент-координатор – экземпляры агентов-координаторов служат для реализации всего цикла обработки запроса пользователя;

• агент-субординатор – или иными словами планировщик, служит для оптимизации нагрузки между агентами-имполнителями;

• агент-исполнитель – выполняет непосредственно задачи, такие как запись в оперативную БД, отправка соответствующих запросов к оборудованию и т.п.

Схема функционирования RM-системы приведена на рис 4.14, а на рис 4.15 приводится архитектура агента.

Рис 4.14. Схема функционирования RM-системы.

Рис 4.15. Архитектура агента RM-системы.

Пользовательские запросы делятся на два класса: типизированные запросы и композитные запросы. Первый тип запросов предполагает, что запрос относится к конкретному уже известному системе типу, для него определены все необходимые входные данные и заранее жестко закодирован специальный метод обработки. Выполнение такого запроса определяется потоком заданий, который хранится в оперативной БД. Агент-координатор исполняет этот поток заданий, преводя заявку из состояния в состояние и обращаясь к определенным методам агентов-исполнителей.

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

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

Реализованный программный комплекс для управления взаимодействием с поставщиками и заказчиками большей частью реализован на платформе Java, благодаря использованию которой в качестве основы для построения системы, удалось добиться мультиплатформенной совместимости. Агентная среда может запускаться на платформах Microsoft Windows, Linux, Solaris. При построении программной архитектуры использовались технологий JavaServlet, XML, ACL, BeeGent, JavaBeans, ODBC, SQL и др. Разработка программных модулей была проведена в средах визуального программирования Borland JBuilder, а также Microsoft Visual Studio. Исходный код программ насчитывает более 10 тысяч строк, лично написанных автором. Программный комплекс внедрен на нескольких предприятиях московского региона.