Доступ к CORBA и Java RMI-приложениям из WebSphere Message Broker V6.1

В этой статье рассказывается, как получить доступ к CORBA (Common Object Request Broker Architecture - стандартная архитектура брокера для выполнения запросов к объектам) и Java™ RMI (Remote Method Invocation - вызов удаленных методов) приложениям из программ, использующих WebSphere® Message Broker. Статья адресована разработчикам приложений для Message Broker, которые хотят добавить в свои процессы обработки сообщений данные из CORBA и Java RMI приложений. Необходимо иметь определенное понимание принципов программирования на Java, CORBA и RMI, а также некоторый опыт в разработке потоков обработки сообщений для Message Broker с помощью элементов JavaCompute и SOAP.

Введение

Программа IBM® WebSphere® Message Broker V6.1 (далее просто Message Broker - промежуточный обработчик сообщений) напрямую не поддерживает технологии CORBA или Java RMI. Однако элемент JavaCompute, добавленный в версии V6, позволяет напрямую вводить код Java™ в Message Broker, так что приложения, основанные на отправке и получении сообщений, могут использовать этот код для доступа к CORBA и Java RMI приложениям. В этой статье рассматриваются следующие темы:

  • обзор CORBA и Java RMI;
  • преимущества получения доступа к CORBA и Java RMI приложениям с помощью Message Broker;
  • когда стоит использовать CORBA и Java RMI;
  • правила, которым стоит следовать;
  • пример, в котором доступ к существующему CORBA-приложению организуется в виде Web-службы.

Обзор CORBA и Java RMI

Технологии CORBA и Java RMI - это два основанных на стандартах механизма, предназначенных для распространения приложений через сеть с помощью RMI (remote method invocation - удаленный вызов методов). Технология CORBA является независимой от платформ и языков, в то время как Java RMI может использоваться только на платформах, поддерживающих Java.

Тем не менее Java-программисты имеют два способа для распространения Java-объектов: CORBA (с использованием Java IDL, Java-реализации CORBA) и Java RMI. В действительности есть и третий способ, разработанный компаниями Sun и IBM: Java RMI через IIOP (Internet Inter-ORB Protocol). IIOP - это протокол, использующийся в CORBA, который был добавлен, чтобы обеспечить совместимость между Java RMI и CORBA.

Преимущества доступа к CORBA и Java RMI через продукт Message Broker

Вот некоторые возможные мотивы для использования CORBA и Java RMI совместно с Message Broker:

  • реализация новых интерфейсов для существующих CORBA-приложений (таких как SOAP и WebSphere MQ);
  • добавление в существующие процессы обработки сообщений данных, которые доступны только из CORBA или Java RMI приложений;
  • перемещение сложной бизнес-логики и обработки данных за рамки Message Broker при сохранении защищенного и надежного механизма для доступа к ним.

Первые два сценария подразумевают, что CORBA- или Java RMI-сервер уже существует, для третьего необходимо реализовать новый CORBA- или Java RMI-сервер, а затем получить к нему доступ из процесса обработки сообщений. Так как продукт Message Broker не является сервером приложений, это может оказаться полезным, когда требуется сложная бизнес-логика.

Использование Message Broker вместе с CORBA и Java RMI избавляет компании от необходимости переписывать приложения, которые изначально были написаны с использованием CORBA или Java RMI. Также это позволяет создавать приложения, которые придерживаются принципов CORBA или Java RMI и делать их доступными из процесса обработки сообщений. Решение использовать одну или другую технологию часто определяется потребностями существующих приложений, но иногда есть возможность выбора. В следующем разделе описаны альтернативы, из которых можно выбрать, и совместимость между CORBA (Java IDL) и Java RMI. Если уже известно, какую технологию планируется использовать, то следующий раздел можно пропустить и перейти к разделам, в которых описывается, как каждый подход реализуется в Message Broker.

CORBA или Java RMI?

При принятии решения о том, какую технологию стоит использовать: CORBA (Java IDL) или Java RMI, обычно не возникает никаких затруднений. Если существующее приложение основано на CORBA (необязательно с использованием Java IDL, это может быть любая реализация CORBA для любого языка), тогда придется выбрать Java IDL. Если существующее приложение написано с использованием Java RMI, тогда необходимо выбирать Java RMI. Однако бывают ситуации, когда обе технологии взаимодействуют между собой, и тогда действительно можно выбирать. Обзор этих ситуаций приведен ниже, а типы взаимодействия описаны в таблице 1.

  • существующее CORBA-приложение, определенное в терминах Java RMI - если IDL исходного CORBA-приложения был определен в терминах Java RMI, тогда можно выбрать способ написания клиента (элемента JavaCompute): с помощью Java IDL или Java RMI IIOP.

  • существующее приложение было разработано с использованием Java RMI IIOP - если исходное приложение было разработано на основе Java RMI IIOP, тогда для элемента JavaCompute можно использовать Java RMI IIOP или Java IDL.

  • разрабатывается внешнее приложение, чтобы избежать хранения больших фрагментов кода в Message Broker - если бизнес-логика разрабатывается за рамками Message Broker, то есть полная свобода выбора между Java RMI или любой реализацией CORBA для создания внешнего приложения. Java RMI обычно проще использовать, в то время как CORBA позволяет выбрать язык программирования из C, C++, SmallTalk и Java. После того как решение принято, для содержимого элемента JavaCompute действуют ограничения, описанные выше.

Совместимость Java RMI и Java IDL
клиент-серверJava IDLJava RMIJava RMI IIOP
Java IDLданетда
Java RMIнетданет
Java RMI IIOPда*нетда

*только когда IDL был объявлен с использованием терминов Java RMI.

Использование CORBA в элементе JavaCompute

Спецификация CORBA поддерживается консорциумом OMG (Object Management Group - группа по развитию стандартов ООП). CORBA версии 2 работает с интерфейсами и объектами, тогда как CORBA версии 3 работает с компонентами. Java IDL - это Java-реализация технологии CORBA, и, как часть JSE 5.0, совместима с CORBA 2.3.1. Так что с этого момента, когда в статье будет упоминаться CORBA, речь будет идти о распределенных объектах, а не компонентах. CORBA-компоненты могут рассматриваться как эквивалент Enterprise JavaBeans-компонентов, а CORBA-объекты - как эквивалент Java-объектов, доступ к которым организован с помощью Java RMI.

CORBA - более мощный стандарт, чем технология Java RMI, с большим числом возможностей и функций, однако и более сложный. Так как CORBA не привязан к конкретному языку, то интерфейсы для объектов определяются в стиле псевдокода с использованием OMG IDL (Interface Definition Language - язык определения интерфейсов). Для каждого языка, поддерживающего CORBA, необходим IDL для привязки к языку и компилятору. Однако в IDL существуют определенные конструкции, которую не имеют прямого отображения в Java.

Листинг 1. Пример IDL-файла для интерфейса Calculator
module ibmdw {
	interface Calculator
	{
		long add(in long x, in long y);
		long subtract(in long x, in long y);
		// использование параметра типа inout
		void square(inout long x);
	};
};

Что потребуется для работы?

Чтобы использовать Java IDL для доступа к удаленным CORBA-серверам, потребуются определенные компоненты, описанные ниже. Полный исходный код представленных примеров доступен в разделе Ресурсы в конце статьи.

IDL-файлы и классы-заглушки (stub classes)

Интерфейсы CORBA определяются с помощью IDL. Необходимо запустить IDLJ-компилятор (IDL to Java) и передать ему IDL-файл CORBA-сервера, чтобы сгенерировать классы-заглушки для Java; это можно сделать командой idlj idlj <idl file name> в каталоге, где находится IDL-файл. Эта команда генерирует сразу несколько файлов, которые будут использоваться в дальнейшем. Если IDL-файлы для CORBA-сервера отсутствуют, то можно использовать CORBA DII (Dynamic Invocation Interface - интерфейс для динамических вызовов), хотя это и сложнее.

Обработка сообщений с использованием компонента JavaCompute

Доступ к CORBA-приложениям осуществляется через компонент JavaCompute, так что нужно добавить один такой компонент в процесс обработки сообщений и ассоциировать его с Java-проектом, щелкнув по нему два раза левой клавишей мыши. Можно оставить значения по умолчанию, а когда будет показан экран с шаблонами, выбрать опцию Creating message class (создать класс сообщения). Затем следует импортировать Java-файлы, сгенерированные IDLJ-компилятором, так как они потребуются для доступа к удаленному CORBA-приложению.

Брокер для обработки запросов к объектам (Object Request Broker - ORB)

ORB - это фактически "мотор" технологии CORBA, выполняющий преобразование сообщений и вызовы к объектам. Java ORB поставляется вместе с Message Broker JSE. Для использования ORB в Java-проектах необходим класс org.omg.CORBA.ORB, который по умолчанию использует ORB, поставляемый со средой Java. Вместо него можно использовать ORB от любого поставщика.

Корректное размещение ORB важно для эффективной работы, так как нежелательно создавать и инициализировать ORB каждый раз, когда через элемент JavaCompute проходит сообщение. На каждый элемент создается только один экземпляр класса элемента JavaCompute, вне зависимости от того, сколько потоков получает к нему доступ, так что рекомендуется создавать ORB в методе onInitialize класса элемента JavaCompute. Можно хранить ORB в качестве поля объекта, если нежелательно, чтобы различные элементы JavaCompute обращались к одному ORB; если это несущественно, можно использовать поле класса (static).

При использовании Java IDL за рамками Message Broker такие свойства, как стартовый порт и хост ORB, передаются в виртуальную машину в качестве параметров, как показано в листинге 2. Однако этот вариант не подходит при использовании элемента JavaCompute, так как виртуальная машина создается самим Message Broker. В таком случае можно закодировать эти свойства в объект Properties, а затем передать его в инициализационный метод ORB, или, еще лучше, использовать в Message Broker свойства, значения которых может определить пользователь, как показано в листинге 3. Это можно сделать прямо перед созданием ORB, желательно в методе onInitialize элемента JavaCompute. В этом случае использование свойств, задаваемых пользователем, позволяет изменять значение этих свойств прямо по ходу работы программы, как в примере, рассматриваемом в этой статье.

Листинг 2. Параметры, передаваемые виртуальной Java-машине
java <Java Server or Client> -ORBInitialPort 1050 –ORBInitialHost 
localhost
Листинг 3. Использование свойств, задаваемых пользователем, для создания ORB
// свойства, значения которых обычно задаются при создании JVM.
Properties p = new Properties(); 
p.put("org.omg.CORBA.ORBInitialPort",(String)getUserDefinedAttribute("ORBInitialPort")); 
p.put("org.omg.CORBA.ORBInitialHost",(String)getUserDefinedAttribute("ORBInitialHost"));

Служба имен

CORBA-клиентам требуются объектные ссылки для вызова CORBA-серверов. Эти объектные ссылки могут быть каким-нибудь способом переведены в строковую форму и отосланы клиенту, или же, чаще, они хранятся в службе имен и выявляются по ходу работы программы. Пример, рассматриваемый в этой статье, использует службу имен, которая находится на исходном порту и хосте ORB. Служба имен поставляется вместе с Broker JSE и может быть запущена командой, показанной в листинге 4. Компонент JavaCompute в общем случае действует как клиент и поэтому использует службу имен внешнего сервера, так что достаточно знать местоположение службы имен и путь к объектной ссылке. При разработке CORBA-приложения с самого начала, как в третьем сценарии, описанном ранее, необходимо запустить и настроить службу имен. Это независимый процесс по отношению к MessageBroker, поэтому он не может контролировать службу имен.

Ссылка на службу имен извлекается через ORB с помощью кода, показанного в листинге 5. Как и в случае с ORB, нежелательно получать ссылку на службу имен каждый раз, когда вызывается процесс обработки сообщений, поэтому надо сделать это в методе onInitialize и сохранить эту ссылку как static-переменную. Служба имен используется только один раз, а затем используется объектная ссылка, полученная из нее, поэтому с точки зрения производительности нет особой выгоды в наличии отдельной ссылки на службу имен на один экземпляр элемента.

Листинг 4. Запуск службы имен на порту 1060
tnameserv –ORBInitialPort 1060
Листинг 5. Получение ссылки на службу имен ORB
NamingContextExt ns = 
NamingContextExtHelper.narrow(orb.resolve_initial_references(NAME_SERVICE));

Объектная ссылка

После того как ссылка на службу имен получена, можно использовать ее для получения CORBA-объекта, точкой доступа к которому является элемент JavaCompute. Это делается с помощью методов для поиска, предоставляемых сервером имен, как показано в примере процесса обработки сообщений, рассматриваемом в этой статье. Управление объектной ссылкой может быть более сложным, нежели управление службой имен и ORB. Опять же необходимо найти эту ссылку только один раз, а затем сохранить ее в качестве static-переменной или переменной объекта. Но если CORBA-сервер будет перезапущен, а, следовательно, создаст новую объектную ссылку, имеющаяся объектная ссылка станет недействительной, что приведет к возникновению исключительных ситуаций при попытке вызова ее методов. Поэтому необходимо добавить бизнес-логику для обработки исключительных ситуаций и обновления объектной ссылки через службу имен.

Бизнес-логика

Теперь в метод evaluate элемента JavaCompute необходимо добавить логику, для извлечения входных данных из древовидной структуры сообщения Message Broker, использовать их для вызова CORBA-сервера и отправить результат запроса обратно в древовидную структуру сообщения. Пример ниже показывает, как сделать это, используя мастер Start from WSDL or XSD (запуск через WSDL или XSD) для генерации набора сообщений, а затем используя XPath в элементе JavaCompute для манипулирования древовидной структурой сообщения. Этот способ предпочтителен, так как он ведет к стандартной и относительной простой логике в элементе JavaCompute.

Использование Java RMI в компоненте JavaCompute

По сравнению с CORBA у Java RMI более простая спецификация и удобная в использовании модель программирования. Изначально в Java RMI использовался собственный протокол, но более поздние версии уже поддерживали IIOP, который был добавлен, чтобы позволить Java-разработчикам программировать в более простой и знакомой модели Java RMI при разработке приложений, совместимых с CORBA-клиентами.

Что для этого потребуется?

Java-классы

В отличие от Java IDL, здесь требуется начинать не с IDL-файла, а с Java-интерфейса, который наследует интерфейсу java.rmi.Remote и каждый метод которого должен выдавать исключительную ситуацию java.rmi.RemoteException. Пример удаленного интерфейса (remote interface) приведен ниже. До выхода JSE 5.0 необходимо было пропускать удаленный интерфейс через компилятор rmic, чтобы сгенерировать классы-заглушки, но теперь этого делать не надо, что еще больше упрощает использование Java RMI.

Листинг 6. Удаленный Java-интерфейс
package compute;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface Calculator extends Remote {
    public int add(int x, int y) throws RemoteException;
    public int subtract(int x, unt y) throws RemoteException;
    public int square(int x) throws RemoteException;
}

RMI-реестр

RMI-реестр (RMI registry) можно рассматривать как аналог службы имен в Java IDL. Как и в Java IDL, RMI-реестр - это внешний процесс, поставляемый с JSE, который можно запустить командой rmiregistry. Компоненту JavaCompute, когда он выступает в качестве клиента, необходим доступ к RMI-реестру сервера для получения ссылки на Java-объекты, доступ к которым открыт с использованием Java RMI. Как и в случае со службой имен и ORB, важно, где будет храниться ссылка на RMI-реестр. Она может быть как статической переменной, так и переменной объекта.

Ссылка на объект

Ссылка на Java-объект извлекается из реестра с помощью метода lookup. Проверки, которые были написаны в разделе, посвященном работе с объектными ссылками в CORBA, необходимо выполнять и в сценариях, использующих Java RMI.

Менеджер безопасности

Для Java RMI необходимо наличие менеджера безопасности (security manager), чтобы можно было выполнять загрузку или запуск любого удаленного кода. Менеджер безопасности создается один раз в конструкторе компонента JavaCompute:

Листинг 7. Код для создания менеджера безопасности
if (System.getSecurityManager() == null) {
    System.setSecurityManager(new SecurityManager());}

Аспекты, которые необходимо учитывать при доступе к внешним приложениям из элемента JavaCompute

  • Производительность. Вызов Java RMI или CORBA-приложения выполняется в синхронном режиме. Поток, в котором выполняется процесс обработки сообщений, блокируется до получения ответа от внешнего приложения. Можно использовать возможность создания дополнительных экземпляров Message Broker для повышения производительности в случае с повышенной рабочей нагрузкой.
  • Транзакции. Message Broker не управляет внешним приложением, и поэтому оно не может участвовать в скоординированных транзакциях. Поэтому логику для обработки ситуации с откатом транзакции (rollback logic), в которой участвуют CORBA- или Java RMI-сервер, необходимо прописывать отдельно.

Добавление SOAP-интерфейса к CORBA-серверу

Одной из причин для доступа к CORBA- и Java RMI-приложениям является желание сделать их доступными через новый интерфейс, такой как SOAP, чтобы использовать их в виде Web-сервиса. В следующем примере показано, как сделать это, и представлен весь исходный код, включая процесс обработки приложений и архивный файл для Message Broker, которые можно загрузить из раздела Ресурсы.

Пример калькулятора

Примером в этом разделе выступает простой объект-калькулятор, IDL-файл которого был приведен в листинге 1 выше. У него есть три метода: сложение (add), вычитание (subtract) и возведение в квадрат (square). На этом примере можно получить основные знания, необходимые для представления новых интерфейсов для существующих CORBA-приложений или внесения в процессы обработки сообщений данных из CORBA-приложений.

Процесс обработки сообщений

Процесс обработки сообщений может быть простым или сложным в зависимости от поставленной задачи. Можно представить несколько CORBA-объектов как один Web-сервис или представить в виде Web-сервиса только подмножество методов CORBA-объекта. Процесс обработки сообщений, рассматриваемый в этой статье, представлен на рисунке 1. В нем есть три функциональных элемента: SOAPInput (входные данные в формате SOAP), SOAPReply (выходные данные в формате SOAP) и элемент JavaCompute, который содержит CORBA-логику. Трассировочные узлы (trace nodes) добавлены для отладки и получения информации. Альтернативный вариант процесса обработки сообщений показан на рисунке 2. Этот вариант не рассматривается в статье и использует компонент RouteToLabel (маршрутизатор), который вызывает компонент, соответствующий выбранной операции, вместо размещения этой логики внутри элемента JavaCompute, как будет показано ниже. Компонент SOAPInput автоматически позволяет использовать компонент RouteToLabel для выбора элемента, в зависимости от названия операции, что может быть удобно, если необходимо организовать доступ к нескольким CORBA-серверам или если логика для разных операций различается настолько, что правильнее будет разделить ее между разными элементами JavaCompute.

Рисунок 1. Пример процесса обработки сообщений
Рисунок 1. Пример процесса обработки сообщений
Рисунок 2. Альтернативный вариант процесса обработки сообщений
Рисунок 2. Альтернативный вариант процесса обработки сообщений

SOAP-элементы конфигурируются через WSDL-файл, который эквивалентен IDL-файлу. Отображение WSDL-файла в IDL-файл описывается в спецификации OMG (см. раздел Ресурсы), а для выполнения преобразования существуют компиляторы с открытым исходным кодом. WSDL-файл импортируется мастером Start from WSDL and/or XSD files из набора инструментов Message Broker, а затем перетаскивается на компонент SOAPInput для конфигурирования.

У процесса обработки сообщений есть еще один необязательный параметр - UDP-объект (User Defined Properties - свойства, определенные пользователем), в котором хранятся порт и хост, где запущен ORB. Они позволяют изменять конфигурацию приложения при развертывании и во время работы без внесения изменений в приложения. Параметры UDP показаны на рисунке 3.

Для генерации набора сообщений рекомендуется использовать компилятор из IDL в WSDL/XSD. Простые типы данных легко отображаются из IDL в XSD, но можно отобразить и сложные типы данных, такие как структуры и объекты. При использовании компилятора из IDL в Java сложные типы, сгенерированные в XSD/WSDL-файлах, будут отображены на Java-объекты через get и set-методы для каждого атрибута, предоставляя определенный способ для сохранения информации из древовидной структуры сообщения в запрос к CORBA-серверу и помещения результата этого запроса обратно в древовидную структуру сообщения.

Рисунок 3. Форма для определения UDP
Рисунок 3. Форма для определения UDP

Java-проект

Java-проект, развертываемый для приведенного выше примера процесса обработки сообщений, содержит CORBA-логику, позволяющую этому процессу обращаться к CORBA-серверу. При этом следует обратить внимание на:

  • импортированные файлы, которые были сгенерированы IDLTJ компилятором;
  • статические переменные, в которых хранятся ссылки на ORB, службу имен и активная ссылка на объект;
  • метод onInitalize, в котором находится логика, получающая ссылки на ORB, службу имен и сам объект, при этом информация о каждом событии записывается в системный журнал;
  • метод evaluate, который вызывается каждый раз, когда сообщение проходит через компонент JavaCompute. Он определяет, какая операция была вызвана, извлекает входные параметры из древовидной структуры сообщения и использует их для вызова CORBA-сервера. Затем он помещает результат вызова обратно в древовидную структуру сообщения, чтобы компонент SOAPReply мог сгенерировать выходное SOAP-сообщение.

CORBA-сервер

CORBA-сервер разработан на основе стандартного механизма POA (Portable Object Adapter - переносимый адаптер для объектов). Он создает свой экземпляр ORB и получает ссылку на службу имен, точно так же, как это делает компонент JavaCompute. Затем создается объект Calculator, "обрезается" (narrow - один из терминов технологии CORBA) и публикуется в службе имен. В конце запускается ORB, из-за чего текущий поток блокируется, а ORB остается работать и может обрабатывать запросы.

Установка и запуск приложения

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

  1. Запустить службу имен, используя команду из листинга 4.
  2. Загрузить файл типа Project Interchange для набора инструментов Message Broker и импортировать его в установленный набор инструментов с помощью команд меню: File (файл) => Import (импортировать) => Other (другой тип) => Project Interchange. После этого в рабочем пространстве должны появиться четыре проекта.
  3. Запустить CORBA-сервер: Проект JavaIDLServer содержит класс Server. Необходимо запустить его метод main, который напечатает в консоли, что объект был создан и ссылка на него помещена в службу имен.
  4. Установить процесс обработки сообщений, для чего в рабочей области должны быть четыре элемента CalculatordW, CalculatordWMessageSet и CalculatorJava. Можно использовать тестовый клиент Message Broker для развертывания и вызова процесса обработки сообщений или вручную установить BAR и вызвать процесс с помощью HTTP-инструмента, такого как nettool.

При вызове процесса обработки сообщений SOAP-сообщение из тестового клиента Message Broker пересылается в компонент SOAPInput, затем компонент CORBARequest типа JavaCompute использует информацию из древовидной структуры для вызова Java IDL сервера. После этого компонент JavaCompute помещает ответ сервера обратно в древовидную структуру сообщения и отправляет его тестовому клиенту через компонент SOAPReply.

Заключение

В этой статье было показано, как использовать элемент JavaCompute для доступа к CORBA- и Java RMI-приложениям, чтобы добавить данные в процесс обработки сообщений или предоставить новый интерфейс для уже существующих приложений. На примере было продемонстрировано, как добавить SOAP-интерфейс к CORBA-приложению и как просто организовать взаимодействие между Web-сервисами и CORBA с помощью Message Broker. С этими знаниями можно быстро, не переписывая существующие приложения, открыть доступ к ним для новых пользователей. В разделе Ресурсы приведены ссылки на источники с дополнительной информацией о продукте WebSphere Message Broker V6.1 и технологиях CORBA и Java RMI.


Загрузка

ОписаниеИмяРазмер
пример кодаCorbaDw.zip49 KB

Ресурсы

  • Accessing CORBA and Java RMI applications from WebSphere Message Broker V6.1: оригинал статьи (EN).
  • Using Java in WebSphere Message Broker V6 (EN): статья на портале developerWorks с техническим обзором расширенных возможностей поддержки Java в WebSphere Message Broker V6.
  • Getting Started with Java IDL (EN): различные статьи и учебные пособия компании Sun, знакомящие с Java IDL.
  • Java IDL: Mapping IDL to Java (EN): спецификация отображения типов данных IDL на типы данных Java, подготовленная компанией Sun.
  • Java RMI over IIOP (EN): статья от компании Sun с техническим обзором спецификации Sun Java RMI over IIOP и основанных на этой технологии продуктов.
  • Java RMI (EN): техническая информация по стандарту Java RMI, предоставленная компанией Sun.
  • Object Management Group (EN): техническое описание стандартов CORBA и IDL от консорциума OMG.
  • CORBA home page (EN): техническое описание и спецификаций таких CORBA-технологий, как IDL и IIOP.
  • CORBA to WSDL/SOAP Interworking (EN): техническая информация по отображению типов данных IDL в типы данных WSDL от консорциума OMG.
  • Страница для разработчика WebSphere Message Broker (EN): технические ресурсы по использованию WebSphere Message Broker для соединения и глобальной трансформации данных, а также для высококачественной интеграции различных служб, платформ и приложений для развития SOA-решений.
  • Страница продукта WebSphere Message Broker (EN): описание и новости о продукте, информация о тренингах и поддержке и многое другое.
  • Центр информации WebSphere Message Broker (EN): отдельный Web-портал со всей документацией для WebSphere Message Broker V6, с теоретической, практической и справочной информацией об установке, настройке и использовании WebSphere Message Broker.
  • Библиотека документации по WebSphere Message Broker (EN): различные спецификации и учебные пособия для этого продукта.
  • Страница поддержки для WebSphere Message Broker (EN): база данных с возможностью поиска по проблемам поддержки Message Broker и их решениям, а также файлы и патчи для загрузки, отслеживание состояния известных проблем и многое другое.
  • Redbook: Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB (EN): Шаблоны для электронной коммерции - это группа проверенных сценариев, которые можно использовать для ускорения разработки и развертывания приложений для электронной коммерции. В этом учебнике рассматривается, как использовать WebSphere ESB вместе WebSphere Message Broker для реализации ESB в рамках SOA. В книгу включены сценарии, описывающие проектирование, разработку и развертывание.
  • Страница с ресурсами для разработчиков SOA-решений на платформе WebSphere (EN).

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, Технология Java
ArticleID=621450
ArticleTitle=Доступ к CORBA и Java RMI-приложениям из WebSphere Message Broker V6.1
publish-date=02042011