Что делает заглушка на стороне сервера? А что такое скелет?
Это диаграмма из Википедии. Я установил заглушку как на серверной машине, так и на клиентской машине. Я понимаю, что заглушка помогает в сети на стороне клиента, но что делает заглушка на стороне сервера?
Также в приведенном выше рисунке, что означает скелет?
посмотрите следующее изображение:
Чтобы быть коротким, stub и скелет являются аналогами в настройке веб-службы. Skeleton belongs to service provider side и stub belongs to receiver side. На нижнем уровне заглушки и скелета общаются друг с другом.
С клиентской стороны бизнес-объекты обмениваются данными с заглушками, а заглушка берет на себя ответственность за сообщение и вызывает веб-службу. После того, как вызов выполняется на стороне поставщика услуг, скелет является параллельным объектом для заглушки, и он получает сообщение запроса и понимает его и передает информацию бизнес-объектам служебной стороны.
Шкура и скелет скрывают некоторую сложность.
Заглушка скрывает сериализацию параметров и связь на сетевом уровне, чтобы предоставить вызывающему абоненту простой механизм вызова.
Скелет отвечает за отправку вызова фактической реализации удаленного объекта.
http://docs.oracle.com/javase/7/docs/platform/rmi/spec/rmi-arch2.html
Первое, что вам нужно сделать, это забыть о скелетах. Они устарели в течение 13 лет.
Контейнер создается удаленным объектом при его экспорте. Затем он либо привязан к реестру, либо получен клиентом с помощью поиска, либо он возвращается непосредственно клиенту в результате использования другого удаленного метода.
Затем клиент использует заглушку в качестве реализации соответствующего удаленного интерфейса, чтобы выполнить сетевую часть RMI, взаимодействуя с JVM сервера, чтобы в конечном итоге вызвать тот же метод в удаленном объекте, который клиент вызывает в заглушке.
Ключом к пониманию "заглушек" и "скелетов" является понимание концепции marshalling:
rmiregistry - это просто средство поиска; больше ничего. Когда сервер выполняет bind(), он "регистрирует" себя с помощью rmiregistry. Когда клиент выполняет lookup(), он проверяет, что зарегистрировано на сервере. Ничего больше, не меньше.
Я не думаю, что имеет смысл придираться к терминологии вроде "скелетов". Если вы предпочитаете, вы можете назвать все "заглушкой". Дело в том, что оба являются PROXIES, оба делают MARSHALLING, одна сторона существует под клиентом (на который клиент вызывает), а другая сторона существует на сервере (скелет вызывает фактический код сервера).
Надеюсь, мое объяснение и пример помогли в вашей другой ссылке помогли (по крайней мере, немного).
Я остановлюсь только на том, почему заглушка должна быть как на стороне сервера, так и на стороне клиента. Еще один вопрос уже был дан.
Когда экспортированный удаленный объект передается удаленному объекту, либо как аргумент метода, либо возвращаемое значение, происходит следующее. На серверной машине создается заглушка. Затем он сериализуется, отправляется по сети на клиентскую машину и десериализуется там, чтобы сделать идентичную копию заглушки. После этого заглушка больше не нужна на клиентской машине.
Вот типичный сценарий.
Таким образом, одно использование наличия заглушки на стороне сервера так, что оно может быть сериализовано и (его копия) отправлено на другие машины, например, как часть привязки. Аналогичным образом, когда клиент выполняет поиск, реестр выполняет сериализацию своей копии (ss1) и отправляет ее клиенту.
Штук для удаленного объекта действует как локальный представитель клиента или прокси для удаленного объекта. Заглушка скрывает сериализацию параметров и коммуникацию на уровне сети, чтобы предоставить пользователю простой механизм вызова.
В качестве альтернативы рассмотрите программу, запущенную на одной машине: каждый метод является ветвью. Когда вы перемещаете метод на удаленную машину, вы обрезаете ветку, оставляя заглушку, которая содержит только сообщения.
Источник
В удаленной JVM каждый удаленный объект может иметь соответствующий скелет. Скелет отвечает за отправку вызова фактической реализации удаленного объекта.
И скелет, который я рассматриваю как первую реализацию - то, что удовлетворяет вызывающему соглашению, выполняет частичную операцию и удовлетворяет удовлетворительно.
Форма Oracle