Да ничего не скажу. Не-java приложения меня не интересуют  Если заинтересуют - сделаю внешний мост.


Из-за 2-5% выигрыша? 


Я вам не скажу за всю Одессу, сами понимаете. Скажу только за себя и известных мне коллег - всё не так, как вы расписали. Редактор форм я не использую по иным причинам - они создают отвратительный, неподдерживаемый код и не могут утилизировать все возможности swing-компонент. Вот и всё. Зависимость от конкретного редактора мне совершенно не страшна, равно как и мнимое "отсутствие контроля" 


Ничего не имею против. Хотите свой протокол (вместо RMI) - реализуйте. Я не имею целью обсудить, какие средства предоставляет RMI, для того чтобы получить в результате совсем иной протокол. Я не пойму, чем повинен RMI?

А чё, обычные сервисы не подойдут?

ну, на самом деле я думаю тут пахнет в побольше процентами (конечно ничем не подкрепленно).

Спасибо вам за то, что вы постоянно разрушаете закоренелые стереотипы. Но, я, пока, останусь при своем выборе.

Добавлено через 14 минут и 38 секунд

Не спорю, что это изречение голословно, но все же народ к RMI так относится 

Это сообщение отредактировал(а) Platon - 3.1.2008, 10:32

Подвожу свои итоги: для соединения клиент сервер однозначно использую Apache MINA, для внутреннего взаимодействия серверных машин между собой, конечно неплохо использовать RMI

Строить обмен между компьютерами на сериализованных обьектах удобно, если ассортимент обьектов велик, а интенсивность обмена невысока. Если ассортимент узок, но высокая интенсивность, то становится выгоден свой протокол. Например, 10 сообщений, но каждое передается по несколько миллионов за день. Каждому клиенту. Тогда экономия нескольких байтов имеет смысл. 

Оффтоп: RMI был задуман как технология, максимально упрощающая сетевое программирование. Программисту не требуется знать слова "сокет". Однако в свое время мне было проще разобраться с сокетами. Возможно по этой причине я и не использовал RMI. 



В нетбинсе вполне нормально получается. А все возможности свинга трудно знать, если сталкиваться с ним эпизодически.

Это сообщение отредактировал(а) COVD - 3.1.2008, 22:24

Чего-то набрел я на эту уже старую тему и вспомнилось мне. Потому не спора ради, а просто так.



RMI (Remote Method Invocation) - это имитация вызова метода. "Дай обьект". И этот обьект возвращается одним куском. Даже если обьект - коллекция. Очевидно, сначала вся коллекция формируется на передающей стороне (размещается в памяти), потом вся коллекция пересылается спрашивающему (размещается в памяти) и только после этого спрашивающий получает ссылку на готовый обьект. 

Совершенно по-другому работает ResultSet, который можно было бы назвать RI , т.е. Remote Iterator.  Там элементы коллекции становятся доступны на приемной стороне по мере их готовности. Нет необходимости размещать в памяти всю коллекцию.

Сделать коммуникацию "a la ResultSet" можно и в RMI, но, на мой взгляд, ненатурально получится. Но далеко не везде эти нюансы актуальны.  

У меня сомнения относительно коммуникации "a la ResultSet" вообще. Что это за вид коммуникаций такой? При использовании RMI передаётся не куча объектов одним куском и не куски объекта. Передаётся всё любое - как/что напишете, так/то и будет. Хотите передавать коллекцию целиком - пожалста. Хотите удалённый итератор (или тот же ResultSet) - пожалста. Где "особенности" коммуникации, в упор не вижу.

Это сообщение отредактировал(а) w1nd - 18.8.2008, 14:47

И как это будет выглядеть на RMI? Наверное, надо реализовать метод next(). При каждом к нему обращении будет посылаться запрос на удаленный компьютер, который в ответ вернет очередную порцию данных (строку из таблицы). Это я и назвал "a la ResultSet". Или есть другой способ? 

P.S. Вот поиск дал org.apache.jackrabbit.rmi.remote.RemoteIterator - апачевская пристройка "to control the amount of buffering used to increase performance". Наверное, в сановском RMI этого нет.  


Это сообщение отредактировал(а) COVD - 21.8.2008, 17:56

Вообще-то "a la ResultSet" - это блоками, а не штуками. Но вы описали что-то похожее на правду; так где же "особенности"?



А что, этого нельзя реализовать? Почему это вдруг должно быть в RMI, тогда уж стоит искать что-то вроде RMIJDBC. Хинт: эта фишка тем или иным образом реализована в любом сервере приложений, где есть EJB.

"штуками" - выдает потребителю (как честный итератор), а подгружаются данные - "блоками".  JDBC использует буферизацию, а в классическом RMI ей вроде и нет места. В этом и различие. Очевидно, поэтому и вынуждены создавать конструкции вокруг RMI, когда хотят приблизиться к JDBC по эффективности пересылки коллекций.



Реализуют, как видим, на основе RMI. Потому, что RMI - это "наше все" и не нужно лезть в сокеты? Но "фишка", реализующая обмен данными между компьютерами с буферизацией ( подобно JDBC ) на основе RMI - это уже не RMI в чистом виде, про который пишут в учебниках.  Это "фишка", которую возможно проще и эффективнее было бы делать на сокетах, если бы не необходимость соблюдать стандарты J2EE. Это мое предположение.   

RMI вообще не реализует передачи коллекций или чего-нибудь ещё. RMI предоставляет механизм, на базе которого можно реализовать и что-то "a la ResultSet", и что-то более тупое, для передачи коллекции целиком. 


Не "не нужно лезть в сокеты", а "нет смысла лезть в сокеты". Я вот всех тут третирую, пытаясь понять, где же причины, которые могут побудить отказаться от rmi для внутренних коммуникация и лезть в сокеты. Эффективность? Нет, пока не было примеров. 

И невозможно (некорректно) сравнивать RMI с JDBC, потому что это технологии разных порядков. Более подходящее сравнение - RMI и сокеты. И RMI в "чистом виде" не бывает в принципе, RMI - это база для реализации своей какой-то логики.

Это сообщение отредактировал(а) w1nd - 22.8.2008, 19:33

для внутренних коммуникаций, пожалуй, это хороший вариант. Как раз предстоит подобное, и в срочном порядке собираюсь освежить память по RMI

Я имею в виду коммуникации java <-> java. Для всех прочих использование rmi представляется несколько... затруднительным 

а в чем особенность внутренних коммуникаций? Наверное, решающее здесь - однородность софтвера ( все на java ).



Я тоже пытаюсь понять, что мне мешало использовать RMI. И прихожу к выводу, что, возможно,  это "человеческий" фактор. Мне RMI не представлялся технологией одного уровня с сокетами. Скорее, наоборот, как готовое решение. Ведь RMI предлагает общаться с удаленным компьютером так-же, как и с локальными обьектами. Уж куда проще - все для удобства программиста. Вызов метода, типичная схема запрос-ответ. Но как только что-то не устраивает, то почему-то первая мысль - начать строить на сокетах, а не использовать в качестве кирпичиков RMI, как это сделали в том же jackrabbit, создав целую собственную библиотеку на его основе. Наверное, это действительно вопрос владения той или иной технологией.  

кхе, я вообще-то, под словами внутренние коммуникации подразумевал кое-что другое, т.е. несколько машин объединены в высокоскоростную (локальную) сеть.