|
Spec-Zone .ru
спецификации, руководства, описания, API
|
См.: Описание
| Интерфейс | Описание |
|---|---|
| RMIConnection |
Объект RMI, используемый, чтобы передать запрос MBeanServer от клиента к его реализации MBeanServer на стороне сервера.
|
| RMIServer |
Объект RMI, используемый, чтобы установить соединения с соединителем RMI.
|
| Класс | Описание |
|---|---|
| RMIConnectionImpl |
Реализация
RMIConnection интерфейс. |
| RMIConnectionImpl_Stub | |
| RMIConnector |
Соединение с удаленным соединителем RMI.
|
| RMIConnectorServer |
Сервер соединителя API JMX, который создает основанные на RMI соединения от удаленных клиентов.
|
| RMIIIOPServerImpl |
RMIServerImpl это экспортируется через IIOP, и это создает клиентские соединения как объекты RMI, экспортируемые через IIOP. |
| RMIJRMPServerImpl |
RMIServer объект, который экспортируется через JRMP и это создает клиентские соединения как объекты RMI, экспортируемые через JRMP. |
| RMIServerImpl |
Объект RMI представление сервера соединителя.
|
| RMIServerImpl_Stub |
Соединитель RMI является соединителем для JMX Удаленный API, который использует RMI, чтобы передать клиентские запросы к удаленному серверу MBean. Этот пакет определяет классы, на которые пользователь соединителя RMI должен сослаться непосредственно для обоих стороны клиента и сервера. Это также определяет определенные классы, на которые пользователь не будет обычно ссылаться непосредственно, но это должно быть определено так, чтобы могли взаимодействовать различные реализации соединителя RMI.
Соединитель RMI поддерживает транспорт JRMP для RMI, и дополнительно транспорт IIOP.
Как большинство соединителей в JMX Удаленный API, у соединителя RMI обычно есть адрес, который является a JMXServiceURL. Часть протокола этого адреса rmi для соединителя, который использует значение по умолчанию транспорт RMI (JRMP), или iiop для соединителя, который использует RMI/IIOP.
Есть две формы для адресов соединителя RMI:
RMIServer это дает удаленный доступ к серверу соединителя. С этой формой адреса тупик RMI получается из внешней записи в каталоге, включенной в URL. Внешний каталог является любым каталогом, распознанным JNDI, обычно реестр RMI, LDAP, или Именование COS. Адреса покрываются более подробно ниже.
Обычный способ создать сервер соединителя RMI состоит в том, чтобы предоставить адрес соединителя RMI к методу JMXConnectorServerFactory.newJMXConnectorServer. Сервер MBean, к которому присоединяется сервер соединителя, может быть определен в качестве параметра к тому методу. Альтернативно, сервер соединителя может быть зарегистрирован как MBean в этом сервер MBean.
Сервер соединителя RMI может также быть создан, создавая экземпляр RMIConnectorServer, явно или через сервер MBean createMBean метод.
Можно выбрать транспорт RMI (JRMP или IIOP), определяя rmi или iiop в protocol часть serviceURL создавая сервер соединителя. Можно также создать специализированные серверы соединителя, инстанцируя соответствующего подкласса RMIServerImpl и предоставление этого к RMIConnectorServer конструктор.
Если serviceURL Вы определяете, имеет пустой путь URL (после того, как дополнительный узел и порт), или если Вы не определяете a serviceURL, тогда сервер соединителя произведет новое JMXServiceURL то, что клиенты могут использовать, чтобы соединиться:
Если serviceURL похож:
service:jmx:rmi://host:port
тогда сервер соединителя генерирует RMIJRMPServerImpl и возвращенный JMXServiceURL похож:
service:jmx:rmi://host:port/stub/XXXX
где XXXX сериализированная форма тупика для сгенерированного объекта, закодированного в BASE64 без новых строк.
Если serviceURL похож:
service:jmx:iiop://host:port
тогда сервер соединителя генерирует RMIIIOPServerImpl и возвращенный JMXServiceURL похож:
service:jmx:iiop://host:port/ior/IOR:XXXX
где IOR:XXXX стандартное кодирование CORBA Взаимодействующей Ссылки на объект для сгенерированного объекта.
Если есть нет serviceURL, должен быть предоставленный пользователем RMIServerImpl. Если toStub метод на этом объекте возвращает экземпляр Stub, тогда сервер соединителя генерирует a JMXServiceURL использование iiop форма выше. Иначе, это генерирует a JMXServiceURL использование rmi форма.
host в предоставленном пользователем serviceURL является дополнительным. Если существующий, это копируется в сгенерированный JMXServiceURL но иначе проигнорированный. Если отсутствующий, сгенерированный JXMServiceURL будет иметь локальное имя хоста.
port в предоставленном пользователем serviceURL является также дополнительным. Если существующий, это также копируется в сгенерированный JMXServiceURL; иначе, сгенерированный JMXServiceURL не имеет никакого порта. Для serviceURL использование rmi протокол, portЕсли есть указывает на то, на каком порте сгенерированный удаленный объект должен быть экспортирован. Это не имеет никакого другого эффекта.
Если пользователь обеспечивает RMIServerImpl вместо a JMXServiceURL, тогда сгенерированный JMXServiceURL будет иметь локальное имя хоста в host часть и нет port.
Как альтернатива сгенерированным адресам, только описанным, serviceURL адрес, предоставленный, создавая сервер соединителя, может определить адрес каталога, в котором можно сохранить обеспеченный или сгенерированный RMIServer тупик. Этот адрес каталога тогда используется обоими клиентами и серверами.
В этом случае, serviceURL имеет одну из этих двух форм:
service:jmx:rmi://host:port/jndi/jndi-name
service:jmx:iiop://host:port/jndi/jndi-name
Здесь, jndi-name строка, которая может быть предоставлена javax.naming.InitialContext.bind.
Как обычно, host и :port может быть опущен.
Сервер соединителя генерирует RMIServerImpl основанный на протоколе (rmi или iiop) и, для rmi, port если любой. Когда сервер соединителя будет запущен, он получит тупик из этого объекта, используя toStub метод и хранилище объект, используя данный jndi-name. Со свойствами, определенными API JNDI, консультируются как обычно.
Например, если JMXServiceURL :
service:jmx:rmi://ignoredhost/jndi/rmi://myhost/myname
тогда сервер соединителя генерирует RMIJRMPServerImpl и сохраните его тупик, используя имя JNDI
rmi://myhost/myname
что означает запись myname в реестре RMI, работающем на порту значения по умолчанию узла myhost. Отметьте, что реестр RMI только позволяет регистрацию от локального узла. Так, в этом случае, myhost должно быть имя (или имя) узла, на котором работает сервер соединителя.
В этом JMXServiceURL, первое rmi: определяет соединитель RMI, в то время как второе rmi: определяет реестр RMI.
Как другой пример, если JMXServiceURL :
service:jmx:iiop://ignoredhost/jndi/ldap://dirhost:9999/cn=this,ou=that
тогда сервер соединителя генерирует RMIIIOPServerImpl и сохраните его тупик, используя имя JNDI
ldap://dirhost:9999/cn=this,ou=that
что означает запись cn=this,ou=that в каталоге LDAP, работающем на порту 9999 из узла dirhost.
Если JMXServiceURL :
service:jmx:iiop://ignoredhost/jndi/cn=this,ou=that
тогда сервер соединителя генерирует RMIIIOPServerImpl и сохраните его тупик, используя имя JNDI
cn=this,ou=that
Для этого случая, чтобы работать, API JNDI, должно быть, был сконфигурирован соответственно, чтобы предоставить информацию о какой каталог использовать.
В этих примерах, имени хоста ignoredhost не используется сервером соединителя или его клиентами. Это может быть опущено, например:
service:jmx:iiop:///jndi/cn=this,ou=that
Однако, это - хорошая практика, чтобы использовать имя узла, куда сервер соединителя работает. Это часто отличается от имени узла каталога.
При использовании значения по умолчанию транспорт JRMP фабрики сокета RMI могут быть определены, используя атрибуты jmx.remote.rmi.client.socket.factory и jmx.remote.rmi.server.socket.factory в environment данный RMIConnectorServer конструктор. Значения этих атрибутов должны иметь тип RMIClientSocketFactory и RMIServerSocketFactory, соответственно. Эти фабрики используются, создавая объекты RMI, связанные с соединителем.
Клиент соединителя RMI обычно создается, используя JMXConnectorFactory, с a JMXServiceURL это имеет rmi или iiop как его протокол.
Если JMXServiceURL был сгенерирован сервером, как описано выше под "адресами соединителя, сгенерированными сервером", тогда клиент должен будет получить это прямо или косвенно из сервера. Как правило, сервер делает JMXServiceURL доступный, храня это в файле или службе поиска.
Если JMXServiceURL использует синтаксис каталога, как описано выше под "адресами соединителя, основанными на записях в каталоге", тогда клиент может получить его как только объяснено, или клиент и сервер может оба знать, что соответствующая запись в каталоге использует. Например, если сервер соединителя для агента Whatsit использует запись whatsit-agent-connector в реестре RMI на узле myhost, тогда клиент и сервер может оба знать что соответствующее JMXServiceURL :
service:jmx:rmi:///jndi/rmi://myhost/whatsit-agent-connector
Если у Вас есть тупик RMI типа RMIServer, можно создать соединение RMI непосредственно при использовании соответствующего конструктора RMIConnector.
При использовании транспорта IIOP клиент и сервер может определить что ШАР использовать с атрибутом java.naming.corba.orb. Соединение с ШАРОМ происходит в start время для сервера соединителя, и в connect время для клиента соединителя. Если java.naming.corba.orb атрибут содержится в Карте среды, тогда ее значение ( ORB), используется, чтобы соединить Тупики IIOP. Иначе, новый org.omg. CORBA.ORB создается, вызывая org.omg.CORBA.ORB.init((String[])null,(Properties)null). Более поздний клиент соединителя RMI или сервер в той же самой JVM могут снова использовать этот ШАР, или это может создать другой таким же образом.
Если java.naming.corba.orb атрибут определяется и не указывает на ORB, тогда будет брошен.IllegalArgumentException
Механизм, описанный здесь, не применяется, когда Удаленные объекты IIOP (Тупики или Серверы) создаются и соединяются с ШАРОМ вручную прежде, чем быть переданным к RMIConnector и RMIConnectorServer.
Если клиент соединителя RMI или сервер получают от его коллеги экземпляр class, который он не знает, и если динамическая загрузка кода является активной для соединения RMI, то class может быть загружен с кодовой базы, определенной коллегой. Статья Динамическая загрузка кода, используя Java RMI объясняет это более подробно.
Для дальнейшей ссылки API и документации разработчика, см. Java Документация SE. Та документация содержит более подробные, предназначенные разработчиком описания, с концептуальными краткими обзорами, определениями сроков, обходных решений, и рабочих примеров кода.
Авторское право © 1993, 2013, Oracle и/или его филиалы. Все права защищены.
Проект сборка-b92