Мы работаем над разработкой приложения на основе Java EE. Наше приложение совместимо с Java 1.5 и будет развернуто в WAS ND 6.1.0.21 с пакетами функций EBJ 3.0 и веб-службами. Конфигурация в настоящее время одна ячейка с двумя кластерами. Каждый кластер будет иметь два узла.
Наше приложение или наша система, как я бы сказал, состоит из двух или трех частей.
Часть 1. Разъем, развернутый в одном кластере, который содержит код стороннего поставщика в сочетании с кодом настройки. Их код соответствует стандарту EJB 2.0 и имеет множество интерфейсов Remote Home.
Часть 2. Ухо, развернутое в том же кластере, что и первое ухо. Это ухо содержит EBJ 3, которые делают вызовы в EJB 2, предоставленные поставщиком, и пользовательский код. Эти EJB 3 используются пользовательским интерфейсом JSF, также включенным в EAR, и некоторые из них также предоставляются в качестве веб-служб (JAX-WS 2.0 с соответствием SOAP 1.2) для других клиентов.
Часть 3. Могут быть и другие сервисы, которые не зависят от нашего поставщика / приложения с пользовательским кодом. Этими службами будут EJB 3.0 и веб-службы, развернутые в другом кластере.
В соответствии с рекомендацией некоторых сотрудников IBM, работающих здесь, связь между узлами в кластере может быть EJB RMI. Но если мы пересекаем кластеры и / или другие ячейки, то общение должно осуществляться через веб-сервисы.
Тем не менее, некоторые из нас задаются вопросом о производительности и оптимизации связи для скорости наших приложений, которые будут использовать наши веб-сервисы и EJB. В настоящее время большинство EJB-компонентов выставляются как удаленные. (и наш поставщик настроил их таким образом, вместо того, чтобы также выставлять локальные домашние интерфейсы). Нам интересно, выполняет ли WAS какие-либо оптимизации между приложениями в одном и том же узле / пространстве узлов кластера. Если два приложения установлены в одной и той же области и они вызывают друг друга через удаленный домашний интерфейс, достаточно ли БЫЛО умно, чтобы сделать вызов локальным домашним интерфейсом?
Есть ли у них другие методы оптимизации? Должны ли мы их рассмотреть? Разве мы не должны? Каковы затраты / выгоды? Вот вопрос от одного из членов нашей команды, отправленный в их электронном письме:
Вопрос в следующем: предположим, что мы разрабатываем наши EJB-компоненты в качестве удаленных EJB-компонентов, где код нашего контроллера пользовательского интерфейса взаимодействует с нашими EXT-Java-сервисами через EJB3 ... каковы наши варианты оптимизации производительности, когда EJB-сервер и клиент работают в тот же контейнер?
В качестве справочной информации Google предоставил мне 2000 документов о настройке производительности веб-сферы, в которых объясняется конфигурация настройки, которую можно настроить для включения вызова по ссылке для связи EJB, когда они находятся в одной JVM сервера приложений. В нем говорится следующее:
Поскольку EJB по своей природе не зависят от местоположения, они используют дистанционное программирование.
модель. Параметры метода и возвращаемые значения сериализуются через RMI-IIOP и возвращаются
по значению. Это внутренняя модель RMI «Call By Value».
WebSphere обеспечивает оптимизацию производительности «Нет локальных копий» для запуска EJB
и клиенты (обычно сервлеты) в одной и той же JVM сервера приложений. «Нет местного
Копирование »использует функцию« Call By Reference »и не создает локальные прокси для вызываемых
объекты, когда и клиент, и удаленный объект находятся в одном процессе. в зависимости
в вашей рабочей нагрузке это может привести к значительной экономии накладных расходов.
Настройте «Нет локальных копий», добавив следующие два параметра командной строки в
сервер приложений JVM:
* -Djavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.Util
* -Dcom.ibm.CORBA.iiop.noLocalCopies=true
ВНИМАНИЕ! Параметр конфигурации «Нет локальных копий» повышает производительность за счет
изменив "Call By Value" на "Call By Reference" для клиентов и EJB в одной и той же JVM.
Одним из побочных эффектов этого является то, что производные (не примитивные) параметры метода Java-объекта
на самом деле может быть изменено вызываемым корпоративным компонентом. Рассмотрим рисунок 16а:
Кроме того, в будущем мы также будем использовать Process Server 6.2 и WESB 6.2. Есть идеи? рекомендации?
Спасибо