Технология Клиент-Сервер 2006'4

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Реализация некоторых Java-технологий в WAS CE

Автор: Александр Цимбал
Опубликовано: 18.04.2007

Хотя WAS CE является сертифицированным J2EE-сервером, особенностью практически всех универсальных Java-технологий является наличие специфических черт конкретных реализаций. В данной статье будет рассказано о специфике WAS CE применительно к Web-сервисам и JMX (Java Management Extensions).

Web-сервисы

Web-сервисы являются составной частью технологии J2EE 1.4, поэтому любой сертифицированный J2EE-сервер поддерживает Web-сервисы. Другое дело, что поддержка может быть различной. Для версии 1.x возможны два варианта: поддержка «стандартного» подхода с использованием J2EE, WSDP 2.0 (или нового сервера приложений GlassFish), или использование конкретных реализаций, подобных Axis. Axis как среда создания, развертывания и исполнения web-сервисов является частью Geronimo/WAS CE – jar со всеми необходимыми классами находится в каталоге <install_dir>/repository/axis/jars. К сожалению, в состав WAS CE в настоящий момент не входит полнофункциональной (Web Tools Project для Eclipse имеет множество недостатков, в частности, он поддерживает только использование Axis, а не стандартных средств J2EE) среды создания и развертывания web-сервисов, поэтому многое приходится делать «вручную».

В принципе, наиболее естественной реализацией бизнес-логики сервиса с использованием J2EE являются session-компоненты – собственно, для этого они и созданы. Удаленный (remote) component-интерфейс компонента – интерфейс, содержащий методы, к которым обращается клиент – удовлетворяет всем требованиям, которые предъявляются к Java-интерфейсам для того, чтобы на их основе можно было автоматически сгенерировать WSDL-объявления для этого интерфейса, а на основе WSDL – стабы на стороне клиента. Концептуально проблема решена, остаются только детали – особенности поведения кодогенераторов, опции командных строк и возможности программных оболочек, автоматизирующих или просто облегчающих этот процесс.

Axis

Axis (в настоящее время последней версией является версия 1.4, появившаяся весной 2006 г.) – это совокупность библиотек и утилит, которая позволяет решать все вопросы, связанные с созданием и использованием Web-сервисов на Java. Axis может быть установлен в любой Web-контейнер, соответствующий требованиям спецификации Servlet 2.2.

Возможно, имеет смысл рассмотреть, что представляет собой Axis и какие действия он выполняет при обработке RPC-вызовов.

Основной задачей, которую решает Axis в таком режиме, является получение запроса от клиента через Internet, формирование на его основе некоторой внутренней структуры (объекта MessageContext) и передача этого объекта через цепочку «обработчиков» (handlers) к реализации Web-сервиса.

Получателем сообщения (как правило, но не обязательно, переданного с помощью протокола HTTP), является объект TransportListener – проще говоря, HTTP-сервлет. На основании полученных данных создается объект Message, который затем помещается в объект MessageContext, передаваемый затем от обработчика к обработчику. Основными составными частями объекта MessageContext являются сообщение-запрос (request), сообщение-ответ (response) и набор различных свойств, в том числе свойство serviceHandler, значение которого определяет обработчик, ответственный за выполнение прикладной бизнес-логики.

Сервисом при использовании Axis является экземпляр класса org.apache.axis.handlers.soap.SOAPService, и этот объект обязан содержать так называемый «провайдер» (provider). При выполнении RPC-вызовов провайдер является экземпляром класса org.apache.axis.providers.java.RPCProvider, который и выполняет обращение к серверному Java-объекту, имя класса которого указано в параметре className дескриптора развертывания.

В состав Axis входят две основные утилиты для генерации кода – Java2WSDL (для генерации WSDL на базе Java-интерфейсов) и WSDL2Java – для генерации клиентских стабов на основе WSDL. Разумеется, Axis решает все вопросы, связанные со взаимным отображением XML-типов SOAP и Java.

JAX-RPC

В начале XXI века стала актуальной – по крайней мере, для Sun и JCP – задача создания универсального API для выполнения удаленных вызовов с использованием Java и XML. Эта спецификация – JAX-RPC – была создана. Разработчики этой спецификации прекрасно осознавали, что в ней не оговорены некоторые моменты, которые, вообще говоря, должны присутствовать в универсальной технологии, обеспечивающей выполнение удаленных вызовов, и которые существенно повысили бы ценность этой спецификации для разработчиков и удобства ее использования. Такими характеристиками являются, в первую очередь, поддержка транзакций, обеспечение безопасности при выполнении вызовов, генерация переносимых стабов (на стороне клиента) и скелетов (на стороне сервера). Впрочем, надо при этом иметь в виду, что проработка таких возможностей остается недостаточно детальной и на уровне SOAP или WSDL, поэтому отсутствие поддержки некоторых возможностей, характерных для универсальных систем выполнения удаленных вызовов в JAX-RPC, носит в значительной степени объективный характер – в том смысле, что далеко не все зависело от авторов данной спецификации. Кроме того, JAX-RPC 1.0 базировалась на поддержке SOAP 1.1 – спецификация SOAP 1.2 формально стала стандартом позднее.

Поэтому основные задачи, которые ставили перед собой разработчики спецификации, можно сформулировать так:

Обработка XML RPC-запросов требует наличия как на стороне клиента, так и на стороне сервера специальных библиотек. На стороне клиента необходимо выполнить преобразование вызова удаленного метода в элементы создаваемого SOAP-запроса и сопоставить этот запрос с используемым транспортным протоколом, например, HTTP. На стороне сервера нужно получить и обработать HTTP-запрос, извлечь из него SOAP-сообщение, получить из него параметры запроса и сформировать вызов метода и, наконец, вызвать этот метод для вызываемого объекта. Затем необходимо сформировать отклик (с учетом возвращаемого значения и, возможно, исключения) как SOAP-документ, «вложенный» в HTTP-пакет.

Спецификация оговаривает некоторые обязательные требования, которые касаются серверной части JAX-RPC. Основным контейнером для реализации серверной логики является контейнер Web-компонентов, хотя допустимо создание и использование произвольной run-time системы, построенной с использованием возможностей J2SE (Standard Edition). Наиболее и функциональной run-time средой считается среда, созданная с использованием Web- и EJB-контейнеров в рамках сервера J2EE.

Спецификация JAX-RPC требует обеспечения двух режимов взаимодействия клиентов и серверов при выполнении удаленных вызовов:

Для генерации WSDL и Java-кода с использованием стандартных средств поддержки Wev-сервисов на Java используется компилятор wscompile, который является составной частью WSDP и J2EE SDK (при установке J2EE SDK компилятор wscompile находится в подкаталоге /bin каталога установки).

Создание web-сервиса

В общем случае при создании web-сервиса нужно выполнить следующие шаги:

При использовании в качестве реализации EJB-компонентов задача существенно упрощается – endpoint-интерфейсом, по сути, является remote-соmponent интерфейс компонента, его реализацию берет на себя EJB-контейнер, а WSDL можно сгенерировать на основе интерфейсов компонента.

При использовании компилятора wscompile режимы его работы задаются с помощью специального xml-документа, а также опций командной строки. XML-файл конфигурации задает пространства имен и пакеты, а также содержит полное имя endpoint-интерфейса, например:

<?xml version = "1.0" encoding = "UTF-8" ?>
<configuration 
  xmlns = "http://java.sun.com/xml/ns/jax-rpc/ri/config">
  <service name = "MyService"
    targetNamespace = "http://www.my_company.ru/wsdl"
    typeNamespace = "http://www.my_company.ru/types"
    packageName = "my.company.wsdl_generator_test">

    <interface name = "my.company.wsdl_generator_test.MyEndpointInterface" />
  </service>
</configuration>

При обращении к компилятору wscompile для генерации WSDL-объявлений нужно задать следующие параметры и опции командной строки:

Наконец, в командной строке вызова wscompile нужно задать имя конфигурационного xml-файла, текст которого был приведен выше.

Перед тем, как рассматривать создание клиентских приложений, нужно остановиться на вопросах отображения типов XML и Java. Поскольку смысл использования XML-RPC состоит в выполнении удаленных вызовов из программ, написанных на Java, то вопросы отображения XML-элементов сообщений (и, не менее важно, WSDL-объявлений, описывающих доступные методы) на язык Java (и наоборот) являются одними из самых важных для программиста-практика. Для удобства будем рассматривать отображения XML-Java и Java-XML отдельно.

Отображение элементов XML на Java

Наиболее часто при выполнении удаленных вызовов используются аргументы (и возвращаемые значения) стандартных XML-типов. Спецификация оговаривает соотношение между такими XML-типами и их Java-аналогами (см. таблицу 1).

Обратите внимание на отсутствие стандартного отображения для типа xsd:AnyType. Связано это с тем, что спецификация XML-RPC не требует обязательной поддержки данного типа.

Поскольку на уровне схемы XML возможно сопоставление с типом некоторых дополнительных атрибутов, например, атрибута nillable, то отображение на встроенный тип Java, подобный int, неизбежно при наличии такого атрибута приведет к потере части информации. Вследствие этого, при необходимости на Java вместо встроенного типа (например, int) может использоваться его класс-"оболочка" (java.lang.Integer). Аналогичным образом выполняется отображение для xsd:long (java.lang.Long), xsd:short (java.lang.Short), xsd:float (java.lang.Float), xsd:double (java.lang.Double), xsd:boolean (java.lang.Boolean) и xsd:byte (java.lang.Byte).

Simple Type Java Type
xsd:string java.lang.String
xsd:integer java.math.BigInteger
xsd:int Int
xsd:long Long
xsd:short Short
xsd:decimal java.math.BigDecimal
xsd:float Float
xsd:double double
xsd:boolean boolean
xsd:byte Byte
xsd:QName javax.xml.namespace.QName
xsd:dateTime java.util.Calendar
xsd:base64Binary byte[]
xsd:hexBinary byte[]
Таблица 1. Отображение на Java встроенных XML-типов

Интереснее обстоит дело с массивами. Схема XML позволяет задавать массивы различными способами. Спецификация JAX-RPC ориентируется на «SOAP-ориентированный» синтаксис задания массива, а именно, создание типа «массив» как нового комплексного типа на базе типа soapenc:Array с использованием тега <restriction>, например:

<complexType name = "MyArray">
  <complexContent>
    <restriction base = "soapenc:Array">
      <attribute ref = "soapenc:arrayType"
                 wsdl:arrayType = "xsd:int[]"/>
    </restriction>
  </complexContent>
</complexType>

Такому XML-массиву соответствует Java-массив вида int[ ].

XML-схема поддерживает спецификации двух видов массивов – "обычных" и "полиморфных". Соответственно, для разных видов массивов по-разному выполняется их отображение на Java. Обычные массивы XML отображаются на массивы Java, типом элементов которых являются int, String или некий тип, определенный пользователем. Полиморфные же массивы XML отображаются на массивы вида Object[]. И в том, и в другом случае значения размерностей массива при отображении на Java теряются, т.к. Java не поддерживает значение размерности как часть типа "массив".

Пользователи часто создают собственные типы данных (на уровне XML Schema). Для тех из них, которые создаются с помощью типа xsd:complexType как последовательность (xsd:sequence) или просто неупорядоченная группа элементов (xsd:all) как простых, так и комплексных типов, предусмотрено отображение на Java. Как и следовало ожидать, результатом такого отображения является класс Java с именем, совпадающим с именем XML-типа, который содержит "свойства", соответствующие XML-полям. Как хорошо известно Java-программистам, о наличие "свойства" в компоненте JavaBeans говорит присутствие get- и set-методов специального вида.

Например, для структуры XML следующего вида:

<complexType name = "MyStruct">
  <sequence>
    <element name = "intField" 
             type = "xsd:int"/>
    <element name = "stringField" 
             type = "xsd:string"/>
  </sequence>
</complexType>

будет сгенерирован такой Java-класс:

public class MyStruct 
{
  // ...
  public int getIntField() { ... }
  public void setIntField(int i) { ... }
  public String getStringField() { ... }
  public void setStringField(String s) { ... }
}

Если при задании элементов структуры используются атрибуты maxOccurs или unbound, то на уровне Java создается поле типа «массив», например:

<complexType name = "MyAnotherStruct">
  <sequence>
    ...
    <element name = "stringFields" type = "xsd:string" 
    maxOccurs = "5"/>
  </sequence>
</complexType>

В этом случае фрагмент Java-класса будет иметь такой вид:

public class MyAnotherStruct 
{
  // ...
  public String[] getStringFields() { ... }
  public void setStringFields(String[] s) { ... }
}

Похожим образом осуществляется отображение для перечислений XML (<enumeration>). Создается Java-класс с именем, которое совпадает с именем XML-типа. Для каждого элемента перечисления создаются две константы (одна базового типа – int, String и т.д.), другая – типа самого создаваемого класса. Кроме того, создаваемый класс содержит конструктор, методы getValue() и fromValue(), а также «стандартные» методы toString(), equals() и hashCode(). Общая схема создаваемого класса имеет следующий вид:

public class <имя_enumeration> 
{
// ...
protected < имя_enumeration >(<base_type> value) { ... }

// Генерируется для каждого значения перечисления:
public static final <base_type> _<label> = <value>;
public static final < имя_enumeration> <label>  = 
  new <enumeration_name>(_<label>);

public <base_type> getValue() {...}
public static <enumeration_name> fromValue(<base_type> value) 
{ ... }
public static <enumeration_name> fromString(String value)
{ ... }

// Общие "стандартные" методы генерируемого класса

public String toString() { ... }
public boolean equals(Object obj) { ... }
public int hashCode() { ... }
}

Пример:

<simpleType name = "TrafficLights">
  <restriction base = "xsd:string">
    <enumeration value = "red"/>
    <enumeration value = "yellow"/>
    <enumeration value = "green"/>
  </restriction>
</simpleType>

Такому типу соответствует следующий класс Java:

public class TrafficLights 
{
  protected TrafficLights (String value) { ... }

  public static final String _red = “red”;
  public static final String _yellow = “yellow”;
  public static final String _green = “green”;

  public static final TrafficLights red = 
    new TrafficLights (_red);
  public static final TrafficLights yellow = 
    new TrafficLights (_yellow);
  public static final TrafficLights green = 
    new TrafficLights (_green);

  public String getValue() { ... }
  public static TrafficLights fromValue(String value) { ... }

  public boolean equals(Object obj) { ... }
  public int hashCode() { ... }
  // ... 
}

Важную роль при отображении XML на Java играют также правила отображения WSDL-документа в соответствующие Java-конструкции при генерации на базе WSDL-объявлений стабов клиентских приложений. Поскольку прикладной программист не работает непосредственно с классами стабов, а просто использует их, то подробное описание такого отображение интересно, в первую очередь, разработчику кодогенераторов, генерирующих Java-классы стабов, а не прикладному программисту. Мы не будем подробно рассматривать схему отображения.

Отображение элементов Java на XML

Вторая часть отображения между XML и Java связана с генерацией XML-документов (в частности, WSDL-документов) на базе Java-интерфейсов, характеризующих реализованную функциональность серверов Web-сервисов.

Хотя отображение Java-интерфейсов на XML выполняется автоматически, тем не менее, кратко рассмотрим основные аспекты отображения Java на XML – согласно спецификации JAX-RPC – в первую очередь, для того, чтобы программист имел представления об имеющихся ограничениях.

Согласно спецификации, Java-программист при определении аргументов удаленных методов и их возвращаемых значений должен ограничиться следующими типами данных:

  1. Этот Java-класс должен соответствовать спецификации JavaBeans, т.е. он должен быть public-классом с public-конструктором без аргументов.
  2. Этот класс ни прямо, ни косвенно не должен реализовывать интерфейс java.rmi.Remote, но может реализовывать любой другой интерфейс (или наследовать любой класс Java).
  3. Тип public-полей этого класса должен соответствовать ограничениям для JAX-RPC-типов; класс может также иметь поля другого типа видимости (private или protected).
  4. Если класс имеет свойства в смысле компонентной модели JavaBeans (т.е. присутствуют get- и set-методы соответствующего вида), то тип этих свойств должен соответствовать ограничениям для JAX-RPC-типов.

Для таких типов создается "комплексный тип" XML (тег <complexType>), содержащий набор элементов (тег <all>), например:

<complexType name = "MyType">
  <all>
    <element name = "intField" type = "xsd:int"/>
    <element name = "stringField" type = "xsd:int"/>
...
  </all>
</complexType>

Как видно, эти правила не задают серьезных ограничений при использовании как стандартных, так и созданных программистом типов данных.

Перейдем от типов данных к интерфейсам.

Для того чтобы можно было выполнить отображение Java-интерфейса на XML, необходимо, чтобы данный интерфейс был Remote-интерфейсом, т.е. тем или иным образом наследовал интерфейс java.rmi.Remote. Следует иметь в виду, что при использовании, например, Axis, серверное приложение Web-сервисов можно создавать на основе самого "обычного" Java-интерфейса. Это возможно только потому, что средства, входящие в состав Axis, автоматически генерируют вспомогательный интерфейс, производный от интерфейса java.rmi.Remote, который и использовался при доставке удаленного запроса на сторону сервера. Кроме того, удаленные методы, объявленные в этом интерфейсе, должны объявлять в своем throws-списке исключение java. Имя интерфейса определяет значение атрибута name XML-тега wsdl:portType, а имена методов – значения атрибутов name тегов wsdl:operation.

Компилятор wscompile может генерировать также вспомогательные файлы – файл отображений XML-Java, дескриптор развертывания web-сервиса и др.

Наконец, в WAR-архив нужно добавить ссылку на созданный web-сервис – изменить файл web.xml. Ссылка на web-сервис содержит следующие теги:

<service-ref>
  <service-ref-name>service/MyBusinessLogicService</service-ref-name>
  <service-interface>класс_интерфейса_сервиса </service-interface>
  <wsdl-file>WEB-INF/имя_wsdl_файла.wsdl</wsdl-file>
  <jaxrpc-mapping-file>
    WEB-INF/имя_файла_отображения_xml_java.xml
  </jaxrpc-mapping-file>
  <service-qname xmlns:servicens = "пространство_имен_сервиса">
    servicens:MyBusinessLogic
  </service-qname>
  ...
</service-ref>

Обращение к web-сервису

Для генерации стабов можно использовать тот же компилятор wscompile, но для него нужно задать другой файл конфигурации, который может выглядеть, например, так:

<?xml version = "1.0" encoding = "UTF-8"?> 
<configuration xmlns = "http://java.sun.com/xml/ns/jax-rpc/ri/config"> 
<wsdl 
  location = "file:///My_wsdl_file.wsdl" 
  packageName = "имя_пакета_для_генерируемых_стабов"/> 
</configuration>

Входным параметром является имя WSDL-файла.

Для указания каталога, в который нужно поместить генерируемые файлы, используется опции –s. Опция –gen:Client говорит о том, что создаются файлы для использования на стороне клиента.

Обращение к web-сервису из приложения Java выполняется стандартным образом (на стороне клиента необходимо иметь сгенерированные фалйы стабов). Не нужно забывать, что в настоящий момент WAS CE не имеет глобального контекста службы имен, поэтому обращение возможно только с использованием локального контекста (java:comp/env), и клиентское приложение Java должно выполняться не как независимое приложение, а как клиентское приложение J2EE, т.е. под управлением клиентского контейнера:

InitialContext ctx = new InitialContext();
BusinessLogicService service = 
    (BusinessLogicService) ctx.lookup(
      "java:comp/env/service/BusinessLogicService");
BusinessLogicEndpoint endpoint = 
  service.getBusinessLogicEndpointPort();
endpoint.MyMethod();
...

Вывод. В настоящий момент наиболее удобный способ создания web-сервиса для WAS CE – использование средств и утилит, входящих в состав Axis. Это обеспечивает максимальную автоматизацию процесса и сводит к минимуму «ручную работу».

JMX

Еще одна технология, которая может оказаться удобной при работе с WAS CE – технология JMX.

Суть этой технологии проста. Создана специальная компонентная модель – MBeans. Составной частью информационной системы является специальный сервер, который служит для хранения информации о зарегистрированных в системе Mbean’ах и для управления ими.

Многим разработчикам знаком Jboss – J2EE-сервер c открытым исходным кодом. JBoss использует JMX для управления объектами, из которых строится сам сервер. Другими словами, JMX является неотъемлемой и важнейшей частью его ядра.

При создании WAS CE рассматривался вариант использования JMX как подсистемы управления объектами на уровне ядра сервера, но от такого применения JMX решено было отказаться – всеми этими вопросами занимается компонентная модель GBeans, которая является универсальной компонентной моделью создания серверов приложений. Тем не менее, JMX используется в качестве дополнительной информационной подсистемы, для чего понадобилось реализовать отображение компонентов GBeans на Mbeans и обратно.

JMX может быть использована как удобный способ для получения информации о любых GBean’ах, их атрибутах и операциях. К сожалению, этой информации недостаточно, чтобы быстро и легко перейти на уровень J2EE, т.е. автоматически получать исчерпывающую информацию о сущностях на уровне Java, а не GBeans.

Основные классы, содержащие реализацию JMX, находятся в архивах mx4j-3.0.1.jar и mx4j-remote-3.0.1.jar, которые расположены в подкаталоге /bin каталога установки WAS CE/Geronimo. Путь к этим архивам должен быть известен загрузчику классов при создании приложения.

Рассмотрим основные этапы использования JMX для целей мониторинга объектов и их конфигураций в WAS CE.

В принципе, работа с JMX происходит типичным для Java-технологий образом, а именно: нужно установить соединение с сервисом с помощью соответствующей фабрики соединений. Делается это не с использованием JNDI, а с помощью средств, предоставляемых самой технологией JMX.

Итак, Java-код может выглядеть следующим образом:

package jmx_geronimo_was;

import java.rmi.RMISecurityManager;
import java.util.*;

import javax.management.*; 
import javax.management.remote.*;

public class MainClass 
{
  
  // Задание URL реализации JMX 
  JMXServiceURL url = 
    new JMXServiceURL("service:jmx:rmi://localhost/jndi/rmi:/JMXConnector");

  // Задание параметров для получения соединения
  Map env = new HashMap();
  String credentials[] = new String[2];
  credentials[0] = "system";
  credentials[1] = "manager";
  env.put(JMXConnector.CREDENTIALS, credentials);
  env.put(Context.INITIAL_CONTEXT_FACTORY, 
    "com.sun.jndi.rmi.registry.RegistryContextFactory");
  env.put(Context.PROVIDER_URL, "rmi://localhost:1099");  

  // Установка соединения с JMXCconnectorServer
  JMXConnector connector = JMXConnectorFactory.connect(url, env);
    
//  Получение ссылки на MBeanServer
  MBeanServerConnection mbsc = 
    connector.getMBeanServerConnection();
    
//  Извлечение полезной информации
...

Какая информация может быть полезна в данном случае?

Это имена доменов, J2EE=приложений, J2EE-модулей, информация о типах и именах объектов. Например, следующий Java-код приведет к отображению информации о доменах WAS CE:

  String domain = mbsc.getDefaultDomain();
  System.out.println("Default domain is " + domain);
    
  String domains[] = mbsc.getDomains();
  for (int i = 0; i < domains.length; i++)
    System.out.println(domains[i]);

Выходная информация может выглядеть примерно так:

Default domain is geronimo
openejb
geronimo.boot
geronimo
geronimo.server
geronimo.config
geronimo.maven
geronimo.remoting

Общее число компонентов, а также список их полных имен, можно получить с помощью следующих команд:

System.out.println("Number of MBeans is " + mbsc.getMBeanCount());

  ObjectName on = null;
  Set names = mbsc.queryNames(on, null);
  for (Iterator i = names.iterator(); i.hasNext(); ) 
  {
    System.out.println("\tObjectName = " + (ObjectName) i.next());
  }

Ниже приведены имена для некоторых объектов WAS CE различных типов – для того чтобы читатель мог составить себе краткое представление о структуре WAS CE и ее отображении на Gbeans/MBeans:

Number of MBeans is 157
ObjectName = 
  geronimo.server:J2EEApplication = ear_application,
  J2EEServer = geronimo,
  j2eeType = EJBModule,
  name = beans.jar
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEServer = geronimo,
  JCAResource = geronimo/myjms/1.0/car,
  j2eeType = JCAResourceAdapter,
  name = DemoConnectionFactory
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEModule = geronimo/rmi-naming/1.0/car,
  J2EEServer = geronimo,
  j2eeType = GBean,
  name = SystemProperties
ObjectName = geronimo.server:j2eeType = JVM,
  J2EEServer = geronimo,
  name = JVM
ObjectName = geronimo.server:EJBModule = beans.jar,
  J2EEApplication = ear_application,
  J2EEServer = geronimo,
  j2eeType = StatelessSessionBean,
  name = MySSS
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEServer = geronimo,
  j2eeType = WebModule,
  name = geronimo/welcome-tomcat/1.0/car
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEServer = geronimo,
  JCAResource = geronimo/activemq/1.0/car,
  j2eeType = JCAManagedConnectionFactory,
  name = DefaultActiveMQConnectionFactory
ObjectName = geronimo.server:j2eeType = J2EEServer,name = geronimo
ObjectName = geronimo.config:name = "geronimo/myjms/1.0/car"
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEServer = geronimo,
  ResourceAdapterModule = geronimo/activemq/1.0/car,
  j2eeType = ResourceAdapter,
  name = geronimo/activemq/1.0/car
ObjectName = geronimo.config:name = "servlet_web_app/servlet_web_app"
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEModule = geronimo/j2ee-server/1.0/car,
  J2EEServer = geronimo,
  j2eeType = TransactionManager,
  name = TransactionManager
ObjectName = geronimo.config:name = "ear_application/ear_application"
ObjectName = geronimo.config:name = "geronimo/system-database/1.0/car"
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEServer = geronimo,
  JCAResource = geronimo/myjms/1.0/car,
  j2eeType = JCAManagedConnectionFactory,
  name = DemoConnectionFactory
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEModule = geronimo/activemq-broker/1.0/car,
  J2EEServer = geronimo,
  j2eeType = GBean,
  name = ActiveMQ
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEServer = geronimo,
  j2eeType = ResourceAdapterModule,
  name = console-db-pool-MyDatabaseSource
ObjectName = geronimo.server:J2EEApplication = null,
  J2EEServer = geronimo,
  JCAResource = geronimo/myjms/1.0/car,
  j2eeType = JCAAdminObject,
  name = MyTopic
ObjectName = geronimo.server:J2EEServer = geronimo,
  j2eeType = J2EEApplication,
  name = ear_application

Некоторые другие полезные методы из состава JMX API:

ObjectName on = new ObjectName ("geronimo.server:J2EEApplication = null,
  J2EEServer = geronimo,
  JCAResource = geronimo/myjms/1.0/car,
  j2eeType = JCAAdminObject,name = MyTopic");

  ObjectInstance ref = (ObjectInstance)mbsc.getObjectInstance(on);
  System.out.println(ref);
      
  MBeanInfo beanInfo = mbsc.getMBeanInfo(on);
  MBeanAttributeInfo[]  attributeInfos = beanInfo.getAttributes();
  for(int i = 0; i < attributeInfos.length; i++) 
  {
    System.out.println(attributeInfos[i].getName() + "; type: " 
      + attributeInfos[i].getType());
  }

Таким образом, пользователь может создать собственные инструменты для сбора и отображения информации об объектах информационной системы, в том числе с разбивкой их на классы – например, пулы соединений с БД, различные виды J2EE-приложений, администрируемые объекты JMS и др.

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

Copyright © 1994-2016 ООО "К-Пресс"