Подскажите как XML-RPC клиенту получить от XML-RPC сервера обьект типа ResultSet, ну а xmlrpc-серверу соотвественно как его передать. 

Просьба не писать что то типа : RTFM или пойди по-гугли.   
Спецификацию Я читал, и понимаю что Extensible Markup Language Remote Procedure Call не умеет передавать такие типы данных. Но нет ничего не возможного в этой галактике! 

Может кто то все таки обошел это ограничение???
  


Возможен ли такой вариант : 

Кодировать ResultSet в base64 на стороне сервера , а потом декодировать на стороне клиента обратно в ResultSet ???
  

Никогда не имел дело с XML-RPC, зато представляю, что такое ResultSet. Поэтому рискну ответить: никак. ResultSet - не сериализуемый обьект. Это - буфер сокетного соединения с базой. И содержимое буфера может динамически изменяться. Мы вытаскиваем оттуда строки методом next(), а буфер может синхронно подгружаться из базы. 

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

Это сообщение отредактировал(а) COVD - 13.3.2008, 15:04

Совершенно верно, никак. Но скорее не из-за того, что он не сериализуемый (ResultSet вообще по сети передать не получится никаким способом), а в данном случае из-за ограничений самого XML-RPC, который умеет только простые бины передавать.

Постойте, а как же интерфейс RowSet (и в частности XMLRowSet), который расширяет ResultSet?

Он сериализуемый и отсоединяемый - для того и придуман. То есть RowSet  можно сериализовать и передавать в SOAP Attachment. А XMLRowSet можно, очевидно передавать и в Body.

С год назад пробовал использовать реализацию  RowSet SUN и  Oracle.  Реализация Oracle работает без особых "глюков", а с реализацией SUN были проблемы. Впрочем сейчас, наверное, дело обстоит получше.

Вообще говоря, с XML-RPC все посложнее выглядит за счет того, что он сам попроще. Вот все возможные типы данных: array, base64, boolean, date/time, double, integer, string, struct, nil. Никаких аттачментов нет. В принципе да, можно взять RowSet, сериализовать, закодировать в base64 и так передавать. Или XMLRowSet передавать строкой, а потом парсить. Только кажется гораздо проще перегнать данные в массив бинов и передавать структуры. 

Сам так почти и делал когда стояла почти аналогичная задача - заодно получилось сэкономить траффик (клиенты подключались через GPRS)

Рискну заметить, что сериализация ResultSet не обязательно должна заключаться в попытке записи этого объекта в ObjectOutputStream. Можно передавать параметры для его повторного получения, можно передавать обёртку. А передавать по XML-RPC можно объекты любой сложности - для этого нужно только написать свои сериализатор и десериализатор XML.

ResultSet не имеет смысла в отрыве от сокетного соединения с базой, его породившего. В момент возвращения обьекта ResultSet методом executeQuery() он не обязан иметь в своем буфере всю выборку данных. Он (обьекта ResultSet ), наверное, вообще может быть пуст в этот момент (нечего сериализовать или обертывать!). Очевидно, данные из базы могут синхронно подгружаться по мере вызова next(). Только в этом случае имеет смысл организация доступа к данным a la iterator , т.е. в виде next(). Иначе можно было бы результатом executeQuery  иметь просто ссылку на коллекцию. И отсюда следует. что "повторно" получить или воссоздать ResultSet можно лишь создав новое соединение с базой данных.

Можно создать обёртку ResultSet, которая будет самостоятельно лазить на сервер к реальному объекту ResultSet и дёргать его там. Эту обёртку и десериализовывать.