Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Вивчаю java, дійшов до RMI.
Виникло питання наскільки часто і коли ви використовуєте RMI?
Чуму саме RMI а не SOAP чи JSON/XML/etc через HTTP чи інший transport protocol?
Нет, не используем. Обычно SOAP, REST
Приходилось использовать на суппорте древнего проекта, к которому по загадочным юридическим причином нельзя было подключать никакие сторонние библиотеки, даже опенсорсные. Помню только, что прикрутилось просто и работало хорошо.
RMI, а также CORBA, если ктото еще юзает эту мидлварь, давно пора отправить на свалку истории
А походы для финансов альтернатив с встроенной security & транзакциями как то не наблюдается.
нет, древняя экзотика. В топку вместе с аплетами
Аплеты конечно не огонь, но с ними можно встретиться попав на правку легаси кода
Или в попытках залогиниться в он-лайн банкинг >_<
А можно и нет. Как часто вы пользуетесь он-лайн банкингом?
Я пользуюсь очень часто. Но у меня онлайн банкинг чесное обычное веб приложение. Работает на всех броузерах. Да и у всех знакомых в других банках тоже.
но специально я бы их не учил. Пусть себе лежат :)
Потому что RMI используется в EJB. В чистом виде я даже не знаю где и как RMI можно применить в современных условиях..
Если только учишь Java — смело пропускай. Технология сейчас достаточно экзотична, если вдруг попадется — тогда разберешься. Лучше потратить время на REST/json/xml/JAX-RS — область применимости более широка.
Некоторые связывают RMI только с EJB, что является неправильно. Это очень замечательная , не устаревшая и не сложная технология, которую надо не только знать, но и уметь применять в программах. Сервер RMI пишется в несколько строчек на java, описываются интерфейсы и вызываемые процедуры. Сервер RMI легко заставить работать по SSL протоколу. Сама вышеописанная программа может занять не более
которую надо не только знать, но и уметь применять в программах.
Вот тут бы примеров. Ибо те же веб-сервисы — это куда более высокоуровневая штука.
Я Вас плохо понял, какие примеры? Я бы не сказал что веб сервисы это более высокоуровневая штука. Обе технологии работают по одному принципу. Ни чего в этом нового нет.
Я Вас плохо понял, какие примеры?
Зачем надо (именно «надо», а не просто «полезно») знать и уметь применять RMI?
Я бы не сказал что веб сервисы это более высокоуровневая штука.
То же SOAP может работать по нескольким протоколам и не завязан на Java. REST — это скорее идеология, которая классно сосчитается с HTTP, но при этом теоритечески может быть и без него.
Вы выкинули часть моей фразы — «которую надо не только знать, но и уметь применять». В моем понимании знать что -либо и уметь применять что-либо это разные вещи. У Вас может быть другое мнение.
То же SOAP может работать по нескольким протоколам
Под SOAP вы имеете ввиду Simple Object Access Protocol? Что Вы имеете ввиду — протокол «может работать по нескольким протоколам»? Уточните под «несколькими протоколами» Вы имеете ввиду транспортные протоколы?
В моем понимании знать что -либо и уметь применять что-либо это разные вещи.
А вот теперь я вас плохо понял.
Уточните под «несколькими протоколами» Вы имеете ввиду транспортные протоколы?
Да, транспортные протоколы.
Если взять как меру временные рамки , то слово «знать» у меня занимает от недели до месяца. Допустим мне дали задачу написать программу на языке, который я не знаю. Я его за месяц изучаю и основываясь на моем опыте известного до этого языка пишу программу. Слово «уметь» у меня занимает от трех лет и более лет. В этом случае я могу применить сильные стороны языка, умело обходя его слабые стороны. Это простейший пример.
Так. Чета я ниче не понял. На второй круг:
Это я прочитал так: Обязательными (полезными во многих случаях) навыками являются знание и понимание РМИ.Это очень замечательная , не устаревшая и не сложная технология, которую надо не только знать, но и уметь применять в программах.
И прошу привести примеры тех самых случаев когда РМИ очень полезна и незаменима.
Давайте не будем искать в моих словах тайного смысла. Где я написал обязательная, полезная и не заменимая?
Что значит фраза:Где я написал обязательная, полезная и не заменимая?
?надо не только знать, но и уметь применять
Слово «надо» подразумевает обязательность, или нет?
Это значить что в данном случае знания могут существовать без умения, но умения без знаний нет. Уважаемый, собственно говоря, я должен перед вами отчитываться, оправдываться? Понимайте как хотите. Это Ваши проблемы. Например чтобы понять Ваш предыдущий пост я задал несколько уточняющих вопросов, последний из которых был практически ответом. Уважайте собеседника и тогда диалог будет нормальным.
Уважаемый, собственно говоря, я должен перед вами отчитываться, оправдываться? Понимайте как хотите. Это Ваши проблемы.
Ваапшета цель моего вопроса была «образовательная»: возможно вы бы привели примеры которые я (или кто-то другой) не знал. :)
Это значить что в данном случае знания могут существовать без умения, но умения без знаний нет.
Просто обычно конструкция «не только ..., но и ...» используется как усиление, чтобы подчеркнуть важность второго факта в связке с первым.
Каждый человек индивидуален, для меня это важно.Просто обычно конструкция «не только ..., но и ...» используется как усиление, чтобы подчеркнуть важность второго факта в связке с первым.
Примеров привести не могу(кроме общеизвестного EJB), для этого есть поиск, допустим в гугле.
Все это конечно хорошо, если программа будет работать в intranet или по локалке. А если нет, то получаем проблемы с доступностью портов. Сейчас моден REST. :-)
«моден» значит по умолчанию в большинстве новых начинаний берется REST. А альтернативы нужно обосновывать.
Насколько я знаю REST не сохраняет состояния(stateless), а технологии CORBA, RMI, Web services позволяют делать это(stateful). Вы считаете сохранения состояния устаревшей технологией? Или Вы просто не видите разницы между stateless и stateful и поэтому всегда используете REST?
В абревиатуре REST буква S означает Stateless. Сервер не должен хранить никаких состояний в сессии между запросами, потому что следующий запрос может уйти на другой сервер
Хотя в википедии написано что по поводу буквы S я прогнал
Что мешает зделать чтобы хранило состояние на сервере?
Я где-то читал, что разработчики REST не рекомендовали использовать stateful для REST(типа плохая практика), так как для этого есть другие технологии. К сожалению ссылку не могу найти. Программирование творческая профессия. Все в ваших руках. Ограничений нет. Дерзайте.
Что мешает зделать чтобы хранило состояние на сервере?
Я же написал — потому что следующий запрос может уйти на другой сервер(в класстере). Это делается для более простого load balancing и fault tollerance(иначе если упадет сервер с состоянием, то состояние потеряется)
Ну, это, для определенных задач — логично. Тем не мение, вам поверх, со стороны сервера ситейт зделать — не проблема. Потому это не строгий аргумент в пользу других протоколов.
Хотя я не агитирую за рест, мне больше другие шняги нравятся. Просто обьясняю мотивацию его создателей.
Что мешает зделать чтобы хранило состояние на сервере?
Идеология. РЕСТ — это подход, а не технология типа РМИ.
Но у нее есть свой, выделенный фреимворк.
То есть зря я гнал на дотНетчиков? :)
Читайте документацию. Я не должен Вам чего-либо объяснять.
Сохранение состояния — устаревший (или непопулярный) подход, так как очень плохо масштабируется и усложняет взаимодействия. С другой стороны при большом желании добавить state в REST-оподобный сервис технически очень легко, но плохой тон.
Честно сказать, даже не хотел отвечать на то что Вы написали. Несколько лет назад прочитал на форуме высказывание одного программиста — зачем нужен язык ADA , если есть PHP. Ваши высказывания именно в этом формате. Если Вам не хочется изучать и использовать технологии удаленного вызова процедур, то это не значить что они устарели и их ни кто не использует. REST нельзя сравнивать с CORBA,RMI и WEB сервисами. У них совершенно разные весовые категории. REST — это грамотно составленный http запрос и все. Формат возвращаемых данных не стандартизирован и зависит от воли автора. Тоесть это не технология, а подход. Для работы допустим с WEB сервисами нужно знать WSDL. Как пример могу привести Intel AMT(vPro). Попробуйте заменить WEB сервисы AMT на REST. Или Вы думаете в Intel сидят недоразвитые до «модных» технологий? и ваши знания и опыт стоят выше высококвалифицированных специалистов Intel? Также попробуйте заменить RMI в EJB на REST, наверное программисты SUN тоже не обладают «модной» технологией и их уровень очень низок. Как кто-то написал — REST имеет второе название — «No SOAP», или те кто не хотят изучать SOAP используют REST.
В современной жаве, для того чтобы заюзать веб сервисы WSDL знать не нужно. Это просто классы с аннотациями. Для реста тоже нечто подобное.
А разобраться? А самому научится читать WSDL и на его основе писать запросы к web сервисам и уметь понимать ответы? или в наше время знания не приветствуются?
А разобраться?
Интересно было бы. Если есть инфа (кроме официальной доки на 100500 страниц) кидайте сюда.
А самому научится читать WSDL и на его основе писать запросы к web сервисам и уметь понимать ответы?
Понимать не плохо бы, но утилизация таких знаний крайне низкая. А вот за «писать запросы руками» надо эти же руки и отрывать ... «по самую голову» ©!
Интересно было бы. Если есть инфа (кроме официальной доки на 100500 страниц) кидайте сюда.
В интернете полно информации, ищите, читайте. Я заметил, что Вы постоянно требуете с меня ссылки на информацию или примеры, учитесь самостоятельно их добывать, без сторонней помощи. Лично я предпочитаю читать официальные документы. Кстати, Вы сильно завысили количество страниц.
Понимать не плохо бы, но утилизация таких знаний крайне низкая.
Утилизация любых знаний высокая, по крайне мере понимаешь что делаешь.
А вот за «писать запросы руками» надо эти же руки и отрывать ... «по самую голову»
Вы опять приписываете мне то что я не писал. Хотя, когда получаешь первичные знания то это полезно.
Я ничего не требую :)Я заметил, что Вы постоянно требуете с меня ссылки
Если есть, не необходимая мне на данный момент, инфа которую можно легко получить, почему бы и нет. А вот тратить на ее поиск время — не рационально.
Утилизация любых знаний высокая, по крайне мере понимаешь что делаешь.
«Допустим Земля вращается вокруг Солнца, но как это пригодится мне в моем деле?» © Шерлок, не точная цитата.
А вот тратить на ее поиск время — не рационально.
Я должен за Вас тратить?
«Допустим Земля вращается вокруг Солнца, но как это пригодится мне в моем деле?»
Если Вам не интересна тема удаленных вызовов процедур, тогда почему Вы тратите на это время?
Я должен за Вас тратить?
Если у вас оно уже есть то вам и не прийдетсо, если нет, я не требую чтобы вы это делали.
Если Вам не интересна тема удаленных вызовов процедур, тогда почему Вы тратите на это время?
А я что-тотговорил про удаленные вызовы? Я оппонировал к утверждению:
Утилизация любых знаний высокая, по крайне мере понимаешь что делаешь.
Всдль фреимворки нагенерируют, а для написания запроса можна соапюи тулл заюзать.
Ладно, не буду Вас мучить :-) Используйте фреймворки.
Иногда когда не хочется отвечать — лучше так и делать. А то получится как вот сейчас :)
А сейчас получается все очень просто — «не модно» это значить порок вхождения очень высок, много документации прочитать надо , да понимать как все это работает. А «старо и не перспективно» потому что место в компаниях не светит, которые занимаются решениями допустим на основе CORBA. Хотя Вы правы, в Киеве скорей всего таких компаний нет, поэтому и учить не стоит :-)
много документации прочитать надо , да понимать как все это работает.
По REST меньше? По любой технологии надо много читать и понимать.
Хотя Вы правы, в Киеве скорей всего таких компаний нет, поэтому и учить не стоит
Уверен что есть, точно так же как и не в Киеве: это в основном унылый саппорт дремучей системы, ибо если она качественная, то там уже есть оболочка которая ограждает разработчика от работы с внутрями.
По REST меньше? По любой технологии надо много читать и понимать.
Про REST можно вообще не писать, достаточно пару слов, или небольшой абзац.
это в основном унылый саппорт дремучей системы
Понятно. Если Вы этим не пользуетесь, то значит ни кому это не надо.
Про REST можно вообще не писать, достаточно пару слов, или небольшой абзац.
Очень распространенное заблуждение.
Понятно. Если Вы этим не пользуетесь, то значит ни кому это не надо.
Плохо вам понятно. Поясню: Всегда когда я слышал, слово КОРБА — это был мега-энтерпрайз проект для какого-то банка/страховой на технологиях начала
Расскажите где сложность? Может быть в составлении http запроса?Очень распространенное заблуждение.
все улучшения что надо было вносить — рядом со средним вывести медиану или добавить конферм при уходе со страницы.
Теперь объясните где тут удаленный вызов процедур?
Теперь объясните где тут удаленный вызов процедур?
Вот и я об этом же :) А КОРБА, там постольку по скольку. У вас есть примеры активного использования программистами этой технологии на прямую, расскажите, пожалуйста.
CORBA распространена за бугром и в основном используется в бизнес процессах предприятия. Одна из компаний которая ее использует это Аccenture. Как правило такие проекты индивидуальны, стоят от несколько десятков миллионов евро. Простые смертные на такие проекты не попадают, нужен достаточно высокий уровень знаний. В интернете Вы ни когда не найдете информацию о таких проектах, так как это внутренняя «кухня» предприятия и информацию о ней ни когда не выкладывают.
В любом случае, если вернуться к истокам — вопрос был про RMI для изучения начинающему. Ответ на этот вопрос и на похожий с CORBA’ой вполне очевиден. А для души — да, можно и с ADA поковыряться.
Вовсе и не боги на этих проектах работают, а по технологической части Accenture далекооо не передовики. У них другие сильные стороны — сейлз и менеджмент.
А кто тогда передовики? Те кто использует «модный» REST? Вопрос был о том кто использует CORBA технологию.
В любом случае, если вернуться к истокам — вопрос был про RMI для изучения начинающему. Ответ на этот вопрос и на похожий с CORBA’ой вполне очевиден.
Вы занесли эти технологии в разряд старых и ненужных. При этом сравнили с REST. А это несравнимые вещи.
А кто тогда передовики?
Сами ищите, вам гугл не обязаны в руки давать. Пойнт в том что ссылка на акцентуру в этом контексте неубедительна.
Вы занесли эти технологии в разряд старых и ненужных.
Да. И не только я. В этой ветке более-менее консенсус по этому вопросу наблюдается.
При этом сравнили с REST. А это несравнимые вещи.
Очень даже сравнимые вещи. В конце концов вопрос стоит так: «мне нужно передать сообщение из компонента А в компонент Б». И ответом на это может быть на достаточно высоком уровне абстракции как REST так и CORBA. Так что сравнимы.
Вообщем я заканчиваю эту дискуссию, лично мне она надоела. Переубеждать и чего либо доказывать смысла нет. Больше отвечать не буду.
Аccenture
Простые смертные на такие проекты не попадают
Поржал, акцентура это индийский бодишеп завозящий индусов толпами
Уверены? Они такие же индийцы как и Вы. По крайне мере я знаю только европейцев.
так и в России сидят, и в Германии, Бельгии, Великобритании, США и т.д. Компания очень большая. Я даже на эту тему ни хочу дискутировать. Извините, но больше по поводу этой компании не отвечаю.
В США сидят завезенные индусы, и вообще в компании 3/4-и индусы.
. Вы считаете сохранения состояния устаревшей технологией?
Ну в общем-то да. Хотя это и проще, но не очень хорошо маштабируетсо.
Кстати надо про этот архитектурный подход почитать, там вроде книжка дето была (вы часом не помните?). Ато все «распределенное» с чем я работал, требует стейта в том или ином виде, и никуда от него не дется.
Это:там вроде книжка дето была (вы часом не помните?).
?
Ато все «распределенное» с чем я работал, требует стейта в том или ином виде, и никуда от него не дется.
А никуда и не деваютсо: передают с запросом :)
требует стейта в том или ином виде, и никуда от него не дется.
В идеале все состояние выносится на клиент. В более сложных случаях — заводятся явные сущности (например — http://my_restful_megashop/shop/cart/433423/ ).
Я просто сомневаюсь, что проджектов, которым достаточно дубового стейтлесса — большенство, чтобы говорить что стейтфул «устарел».В идеале все состояние выносится на клиент.
Кстати, вот вам технических вопрос — как вы у себя в РЕСТ мирке релизовуете вызов на сервер с большим временем исполнения? Тупо блочитесь на открытом сокете, пока не зделаеться, или пока сеть не разлучит вас ? :-)
Кстати, вот вам технических вопрос — как вы у себя в РЕСТ мирке релизовуете вызов на сервер с большим временем исполнения? Тупо блочитесь на открытом сокете, пока не зделаеться, или пока сеть не разлучит вас ? :-)
большое — это сколько? стараемся чтобы не было большим.
Ну, например, минут 20. Если у вас специфика такая, что запрос-ответ за пару минут успевает выполнится, то тогда ладно.
Ну от ситуации сильно зависит, и в моих контекстах действительно таймауты на секунды выставлены. Но вообще если сеть и клиенты под контролем — можно их повыключать и ждать себе. Можно как советуют всякими кометами пробовать пользоваться. Но это не совсем вопрос наверное к REST, больше к инфраструктуре и топологии. Хотя «очень RESTful» решение для обхождения длинного запроса могло бы быть вернуть какой-то токен (job_id) и опрашивать его периодически с клиента, то есть да — своего рода состояние на сервере, но становясь явной сущностью (ресурсом) не противоречит REST (в определенных трактовках).
пулинг чего сокета, или стейтфул с вторым запросом «дайте ответ» ?
Зачем стайтфул?стейтфул с вторым запросом «дайте ответ» ?
Просто надо передать еще раз все необходимые данные.
Caching situations; if the information can be cached because of the totally stateless operation of the REST approach, this is perfect.”
ентерпрайз програмеры наплодили такую кучу либ/технологий/фреймворков, что выбрать подходящий сложно :). RMI как технология — очень старая вещь, ей уже около 15 лет, значит напрямую сейчас практически не используют, но можно легко попасть на правку legacy кода в котором будет что угодно.
Чуму саме RMI а не SOAP чи JSON/XML/etc через HTTP чи інший transport protocol ?
технологию выбирают в зависимости от требований проекта. Нужно учитывать маштабируемость, производительность, простоту использования, взаимодействие с другими языками программирования (как вы будете использовать rmi из с++ или питона?)
Напряму RMI ніколи не використовував. Але, технологія RMI over IIOP використана в EJB. Також кажуть, що деякі виробники використовують і інші протоколи, крім RMI-IIOP stackoverflow.com/...-rmi-comparison
Якщо відповідати на питання про використання remote запитів до EJB, то це використовують, так.
1. Enterprise application може бути розподілене на декілька серверів і пов’язане за допомогою EJB (messaging & session beans).
Або ж якщо різні applications на одному сервері, то вряд чи я помилюсь, якщо скажу що вони теж використовують RMI-IIOP для передачі даних один одному через сесійні EJB.
2. Десктопний клієнт може відправляти запити до EJB на сервері.
Чому не SOAP ... я ніколи не вимірював швидкодію ... але думаю, що EJB запити це більш динамічна річ ніж SOAP, причому суттєво. SOAP або HTTP це такі собі «поодинокі» запити. XML потребує серіалізації, яка не слабо «їсть» ресурси.
Так, ми можемо зробити і просто через сокет, з постійним з’єднанням — буде швидко... але легко так може статися, що прийдеться щось дописувати пізніше, якісь ньюанси, свій протокол, а потім ще, і ще... часто буває зручніше і дешевше взяти готовий компонент з якимось вже готовим набором функціоналу. Але, не виключаю, що комусь потрібно і так.
Скажімо, якщо вже є готовий інтерфейс на session EJB, то навіщо мені писати якусь ще обгортку на SOAP, якщо я можу зразу звернутись до session EJB (якщо немає якихось обмежень по безпеці, які не можна було б покрити засобами EJB).
А от якщо я звертаюсь з якогось стороннього application, наприклад на PHP або Perl, то тут вже без SOAP або просто HTTP/JSON ніяк, оскільки сторонні applications на інших мовах не мають можливості передавати дані на session EJB Java (хіба що є якісь спеціальні штуки для .NET абощо, не знаю). Або ж навіть для стороннього Java application, якому я не хочу відкривати нашу «інфраструктуру» ... теж можна взяти або SOAP або ще щось.
P.S. Ще, дуже важливо, що стосується використання EJB на серверній частині — це підтримка транзакцій ... але це все про EJB, а не просто про RMI.
Критерий для меня был, что оно подключается и работает в несколько строк кода.
RMI — очень низкоуровневый. Лично я его использовал, только в универе на лабах.Виникло питання наскільки часто і коли ви використовуєте RMI ?
Его может иметь смысл использовать когда нужна “производительность” или “контроль”. Как правило пишут оболочку и работают через нее.
Это 3 совсем разных подхода. Грубо говоря:Чуму саме RMI а не SOAP чи JSON/XML/etc через HTTP чи інший transport protocol ?
— JSON/XML/etc через HTTP — это более современный подход, но если вы все реализуете руками то могут быть проблемы с интеграцией со сторонними системами. Есть попытка стандартизировать это все, искать по словам REST, JAX-RS. Это больше про обмен данными, но можно использовать и для обмена сообщениями/командами.
P.S. Пыталсо писать понятными словами, к терминам просьба не придератсо.
Pavlo Vasylchenko
Yurii Smyrnov
bsod
Viacheslav
reality_hacker
Нестор Иванович
Viacheslav
двадцатитрёхлетний сениор
Нестор Иванович
Полная трехмерная копия Юры Буряка
Mykola Gurov
Gennadiy Nayda
Bogdan Shyiak
Gennadiy Nayda
Insider
Mykola Gurov
Grez
flyman
Ostap Vyshnya
anonymous
Bogdan Shyiak
88 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів