При работе над мультиагентной системой на java возникла такая задача:

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

Для этого преполагается написать нечто позволяющее:
1) во время работы налету строить графический интерфейс пользователя, тем самым транслировать вопросы удалённого агента в человеко-понятный вид
2) после чего пользователь "вибирает опции, проставляет галочки" - тем самым обрабатывает запрос от удаленного агента
3) затем локальный агент транслирует это всё в машинный вид и отправляет ответ удалённому.

Поясню на примерах:

Есть два независимых сервиса (агенты): А и Б
А - подргужает данные из BD и отправляет B
B - проверяет данные и просит A уточнить кое-какие параметры (например P1 = false/true?)
A - находит данные в базе и доотправляет B
B - обрабатывает их и присылает обратно A 
А - сохраняет результат в BD

Теперь собсно появляется тема этого топика - агент C:
1) его можно подключить вместо A - тем самым роль BD будет играть пользователь
что позволит, например, провести отладку B налету - если ещё не готова BD для A
Аналогично подключить C вместо B, для отладки A.
2) если A не находит что-то в BD то он спрашивает значение  недостающего параметра (P1 = false/true?) у C - то есть фактически преренаправляет запрос к пользователю
...

Так вот. Для решения этой задачи, я, в роли C использую TomCat 6.0 - который генерит на лету станицы на основании ответов/вопросов агента с которым он работает.

Тоесть, например, сейчас мой томкат получает в качестве запроса о значении параметра P1 некоторый инстанс-сообщение класса MessageClass где указано:
что имя параметра - P1,  а список возможных значений - true, false. Получив это сообщение, томкат создаёт группу элементов с выпадающим списоком - всё просто.
-----------------------
Теперь переходим к вопросу, к которому мы так долго шли: как лучше организовать междуагентный "разговор".
Тоесть - как организовать структуру java класса MessageClass, чтобы получить следующие возможности:

1) агент может попросить указать целое и вещественное число из диапазона
2) агент может попросить указать строку подходящую под регулярное вырадение
3) агент может попросить выбрать одну из опций в представленном списке (пример списка: true/false/unknown/not_defined)
4) агент может попросить выбрать несколько опций из списка
5) агент может комбинированный запрос - например: запросить данные паспорта. А данные паспорта состоят из подзапросов где нужно указать имя(String), фамилию(String), Пол( один элемент из множества {male,female})
6) ну и конечно за одну транзакцию могут спрашивать значение не одного параметра

пример: B просит указать дату рождения, имя, фамилию и пол
на что томкат строит форму которая содержит 2 тектовых поля под имя,фамилию, один javascript для указания даты и выпадающий список "Пол: (M/Ж)?"                    

Как организовать структуру MessageClass? 
-----------------------
У меня пока есть 2 варианта:

1)
написать абстрактный класс Request 
и отнего наследовать абстрактный класс NumberRequest
от которого в свою очеред наследовать IntegerNumberRequest и DoubleNumberRequest

однако тут например не понятно вот что: как в классе NumberRequest определить понятие диапазона значений? какого типа будут поля From и To?

далее я создам SetRequest

и в MessageClass создам поле: ArrayList<Request>
 - теперь томкату придётся идти по этому списку и проверять каждого к какому типу запроса он пренадлежит и в соответствии с этим генерировать html код? как это вообще делать?


выглядит как-то сомнительно

2) второй вариант
создать
в MessageClass поля: 
 ArrayList<IntegerNumberRequest> R1;  - список запросов IntegerNumberRequest
 ArrayList<SetRequest> R2; - список запросов SetRequest
 ...
и т.д.

и отдельно список пар  ArrayList<Descript> Order - где



в этом варианте тоже особо радоваться нечему

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



Это сообщение отредактировал(а) Fieral - 4.6.2009, 20:29

Прочитав и постаравшись понять, что именно надо, пришел к таким выводам:

1. Однозначно передавать надо коллекции.
2. А вот дальше неоднозначно:
 а. Наследники какого-то определенного класса.
 б. Классы с реализацией какого-то интерфейса.
 б. Просто список разных классов.
Я бы выбрал интерфейс.

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

чесно говоря, я не понял как это понимать.

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

давайте поговорим об этом 

начнём с простого:

например я хочу запрашивать число из диапазона,
я создам класс Diapazon и начну определять поля From и To 
и тут выяснится что Ява это на матанализ - она разделяет понятие целого и вещественного типов, значит я не могу определить тип полей From и To

тогда есть 2 варианта
1) создать классы IntegerDiapazon и DoubleDiapason у которых поотдельности определить From и To
2) либо создать класс Chislo<T> и класс Diapazon<T> с полями Chislo<T> From; и Chislo<T> To 

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

ваши рекомендации?



Это сообщение отредактировал(а) Fieral - 5.6.2009, 15:46

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

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

а потом их собрать в одну коллекцию и сортировать методом:


?

Это сообщение отредактировал(а) Fieral - 5.6.2009, 17:34

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

а ещё такой вопрос:

например я создам класс SetRequest
там будут поля:


то есть по сути запрос вида: "укажите значение параметра %ParameterName% выбрав один из возможных вариантов из списка ListOfPossibleElements"

а дальше я хочу создать класс BooleanRequest.
и тут есть 2 варианта
1) написать под него отдельный класс - что вынуждает меня исправлять/дописывать код отвечающий за генерацию html`a для него тут:


2) либо унаследовать BooleanRequest от SetRequest указав в конструкторе:



тогда не придётся менять html генератор, НО придётся следить чтобы никто не напихал в список ListOfPossibleElements ничего лишнего (кстати интересный вопрос как это делать?)


ваши рекомендации?


Это сообщение отредактировал(а) Fieral - 5.6.2009, 17:35

Давайте по порядку - невозможно ответчать на 25 вопросов 

1. По поводу генерации HTML.
Как я уже говорил - лучше определить интерфейс, в котором описать те функции, которые нужны для взаимодействия. Ту же функцию, которая будет возвращать HTML для конкретно этого элемента.
Также можно определить функцию, которая будет конвертировать строку (а из HTML скорее всего придет именно строка) в нужные данные.
Ну и так далее.

2. По поводу гибких "классов". Я не большой любитель гибких классов. Слишком гибкие классы будут сложны в использвании. Надо искать что-то более-менее удобное. И здесь как раз потребуется более четкое понимание назначения этих классов.

3. Я бы сделал отдельные классы. Как раз для класса с набором можно было бы использовать Generics для указания того, какие типы данных использовать для доступных значений.

а можно эту фразу расписать попобробнее? 

Ну что-то вроде такого описания (не уверен на счет абсолютной правильности синтаксиса, но где-то так)

угу, но это попрежнему не решает вопроса с BooleanRequest из поста выше

Почему не решается ? Для него можно отдельный класс. Я думаю. что даже нужно.