Применение более сильного кодирования не решает проблему, а только ее маскирует, создавая ложное чувство «защищенности». Правильное решение — ограничение доступа к файловой системе сервера(ов)
А можно подробнее, как это реализовано в WebLogic?
Системы на IBM WAS нормально проходят аудит, что говорит о том, что «проблема» так или иначе решаема.
В статьях по приведенным выше ссылкам это тоже описано.
PS: А зачем «пользователю» доступ на чтение к файлам конфигурации сервера приложений?
When Tomcat needs to connect to a database, it needs the original password. While the password could be encoded, there still needs to be a mechanism to decode it. And since the source to Tomcat is freely available, the attacker would know the decoding method. So at best, the password is obscured — but not really protected. Please see the user and dev list archives for flame wars about this topic.
That said, any configuration file that does contain a password needs to be appropriately secured. That means limiting access to the file so that it could be read only by the user that Tomcat process runs as and root (or the administrator on Windows).
За эту «багофичу» IBM пинают регулярно.
В принципе, можно встроить свой код шифрования паролей, «точка входа» предусмотрена.
Пруф: Enabling custom password encryption
В версии 8.5 (Liberty Profile) появилась возможность «из коробки» кодировать пароли в режиме aes и hash.
Пруф: securityUtility command.
На данный момент на сайте и с помощью SMS-сервиса доступна оплата только баланса проездного билета «Электронный кошелек».
Оплата других видов проездных билетов будет доступна в 2015 году
Т.е. возможность оплаты «проездных» обещается, но в настоящий момент отсутствует.
В каждой реализации должны быть классы org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder, org.slf4j.impl.StaticMDCBinder.
Такая реализация есть и в архиве slf4j-nop-*.jar. Подключение этого архива означает «Сознательное» блокирование вывода SLF4J.
Однако, если не найдена ни одна реализация, то будут использованы классы org.slf4j.helpers.NOPLoggerFactory, org.slf4j.helpers.NOPLogger и org.slf4j.helpers.NOPMDCAdapter, которые находятся в архиве slf4j-api-*.jar.
Это дает основной программе возможность работать, не сваливаясь по ClassNotFoundException.
Для SLF4J практически не раскрыта «вкусность» с подстановкой значений в сообщение (parameterized messages).
Плюсы:
— если оператор логгирования не срабатывает (выключен соотв. уровень), то не тратится время на обращение к объектам, значения которых должны быть подставлены в тело сообщения.
— текст сообщения всегда идет одной строкой.
Пример:
logger.debug("Value {} was inserted between {} and {}.", newVal, below, above);
Поправка по тексту статьи:
Если в classpath не будет найдена реализация логгера ( или заглушка nop) SLF4J гневно ругнется и работать откажется.
Начиная с версии 1.6, если не найдена ни одна реализация, то произойдет переключение на режим «no operation», но работать будет! Это написано в руководстве, второй абзац.
ParagonNTFS — работа с NTFS-разделами. Gemini — поиск и удаление дубликатов файлов, использую в основном для фотографий. Xee3 — просмотр фотографий. NoMachine for Mac OS X — удаленный доступ с любой платформы. Trim Enabler — включение функции Trim для любых SSD-дисков. MPlayerX — проигрыватель видеофайлов.
Расскажу на примере фейла DB2:
Смысл в том, что каждая из 1000 нод обрабатывает только свои данные, тем самым минимизируется сетевой трафик. А если данные для обработки нужно пересылать он нода к ноду, как например в DB2, то это плохо. Поэтому DB2 и загнулась на больших данных.
А можно поподробнее, про какую конфигурацию кластера DB2 идет речь? Database Partitioning Feature или pureScale? Про «загнулась» тоже интересны подробности.
После почти годовой эксплуатации конфигурации Компьютер->HDMI->Телевизор(3D) пришел к выводу что это неудобно и приобрел медиа-плеер с поддержкой 3D.
Плюсы плеера:
+ Управление с одного места, с пульта медиаплеера.
+ Телевизор автоматически переключается в режим 3D, при выборе 3D-режима на плеере.
+ Плеер умеет корректно отображать свое экранное меню в режиме 3D.
+ Плеер умеет проигрывать BD3D-образы (ISO или распакованный), правда без меню (BD-Lite).
+ Компьютер не занят во время воспроизведения фильма.
И тем не менее, уверен, что до сих пор отсутствует нормальная возможность просмотреть содержимое сообщения (payload), ввиде человеческого текста (или XML), а не шестнадцатеричного дампа, который по крайней мере бы можно было скопипастить
Ну и зря вы так уверены в этом. В MQ Explorer это есть. И заголовки можно посмотреть, и сообщение отображается и текстом и HEX-дампом.
В 6.0 также напрочь отсутствует возможность сохранить сообщение на диск.
А окно Put Test Message имеет строку ввода Message Data, куда можно ввести полтора слова, без header-ов.
Оно четко выполняет свою функцию — отправить тестовое сообщение. Если нужно специфичное форматирование и заполнение спец. заголовков — есть IH03(RFHUtil). Он, кстати, тоже позволяет сохранять сообщения на диск и читать их с диска.
Может в 7.0 все гораздо лучше (не прошло и 10 лет), но сильно сомневаюсь. Стиль IBM сырого недописанного барахла соблюдается во всем.
Т.е. у Вас все таки есть какие-то претензии к основному функционалу (доставка сообщений), стабильности, производительности и отказоустойчивости этого продукта (IBM WebSphere MQ)? Если есть, озвучьте пожалуйста. Я пока не увидел ни одной. Он теряет сообщения? Не справляется с нагрузкой? Не реализует заявленные свойства? Есть проблемы при работе через какие-то API?
В чем проявляется его «сырость», кроме того факта что лично вам с ним «неудобно»? И если Вам при работе с этим продуктом было неудобно и непонятно, Вы (или Ваша компания) открыли отчет о проблеме (PMR) в IBM? Попросили поддержки и помощи в их решении?
Озвученное выше выглядит так, как будто Вы продукт «пощупали» мимоходом, даже не прочитав толком документацию, не познакомившись с архитектурой и особенностями. И, кроме того, даете оценку продукта в общем, не указывая версию/платформу, основываясь на мнении N-лет давности. А все меняется, что-то быстрее, что-то медленнее, но — меняется.
А Вы им пользовались? Это тулза под виндовс при помощи которой при желании можно сконфигурировать локальный QM. Сконфигурировать удаленный коннекшн нереально сложно, если вобще возможно.
Пользуюсь, практически каждый день.
Работаю удаленно с менеджерами на Windows, Linux, z/OS.
Действия для подключения к удаленному менеджеру (MQ Explorer V 7.5, который умеет подключатся к менеджерам версии 6.0 и выше):
1. Запустить MQ Explorer.
2. Щелкнуть правой клавишей мышки на разделе Queue Managers
3. Выбрать пункт «Add Remote Queue Manager»
4. Ввести имя менеджера, к которому нужно подключиться. Поле: «Queue Manager Name»
5. Выбрать опцию «Connect Directly».
6. Нажать Next.
7. Ввести параметры соединения:
«Host Name or IP Address» — DNS-имя или IP-адрес сервера
«Port number» — номер порта TCP/IP
«Server-connection channel» — имя канала, через который будет выполняться подключение
8. Нажать Next.
9. Нажать Next.
10. Поставить галку «Enable user identification»
После этого ввести имя пользователя и пароль, которые существуют на сервере MQ.
Поле «Userid» и кнопка «Enter password»
11. Нажать Finish.
Собственно на этом все, можно пользоваться.
Это правда «нереально сложно»?
Похоже, что ваше знакомство состоялось с весьма старыми версиями этих продуктов и как то «не сложилось».
Современные версии продуктов IBM WebSphere MQ, IBM WebSphere Message Broker, IBM WebSphere Application Server и инструментов для работы с ними достаточно приятны в «общении», ИМХО конечно же.
Да, там не все и не всегда «интуитивно понятно». Но, есть документация, которая доступна публично, и легко гуглится, есть форумы, есть тех.поддержка, которая отвечает на самые разные вопросы.
Вообще MQ Series было приобретение IBM, которое не имеет никакого отношения в Websphere. Собственное, ни с чем не совместимое и не следующее никакому стандарту с жуткой внутренней архитектурой, конфигурацией и интерфейсом. IBM кое-как прикрутила к нему джаву и JMS.
А вы точно про IBM WebSphere MQ? Если да то какой версии?
Надежный, кроссплатформенный продукт для быстрой и гарантированной доставки приложений.
При этом, с единым интерфейсом программирования для всех платформ.
При этом с библиотеками для очень многих языков программирования.
Для Java есть или базовые классы MQ, или JMS.
JMS-интерфейс там вполне стандартен, в актуальных версиях является стандартным JCA-адаптером. Те нормально (без шаманств) встраивается в сервера, поддерживающие спецификацию JCA.
В версии 6.x были проблемы с производительностью определенных JMS-операций. Так в версии 7.x перенесли выполнение этих операций с JMS-библиотек на серверную часть MQ. Т.е. современный WebSphere MQ весьма неплохо оптимизирован для работы с JMS-интерфейсом.
Вообще MQ Series было приобретение IBM, которое не имеет никакого отношения в Websphere. Собственное, ни с чем не совместимое и не следующее никакому стандарту с жуткой внутренней архитектурой, конфигурацией и интерфейсом. IBM кое-как прикрутила к нему джаву и JMS. Есть некое подобие графического интерфейса под винду rfhutil, которое требует для подключения переменные окружения. Благо есть поделка школьника под названием WMQTools, ей и пользуемся. JMS к MQ идет отдельным модулем, опять же конфигурируется через зад (там даже своя программка есть с коммандами для создания jndi контекста). А ведь визуальный мониторинг очередей и сбор статистики — это первоочередная задача любого саппорта. Как же это делать, если для этого нет нормальной графической тулзы?
И опять это явно не про тот WebSphere MQ, с которым я знаком.
GUI инструмент, который называется WebSphere MQ Explorer, идет в комплекте уж точно с версии 5.3, про более ранние — не помню. Причем достаточно давно его можно скачать отдельно от серверной и клиентской части. Он бесплатен и весьма функционален. Есть доп. плагины для еще большего расширения функционала. И им же можно генерировать JNDI-описания для Java SE, если вдруг возникает такая необходимость.
Broker вообще рудиментарная вещь. Сегодня полтора человека знают ESQL. Еще меньше пытяются использовать его для трансформаций сообщений, которые на сей день идут в формате XML. Остальные 99.(9)% привыкли юзать для трансформаций XPath, XSLT, и наконец Java. Держать в штате экзотический вид программиста, знакомого с ESQL, когда с той же задачей справится любой другой стандартными на сегодняшний день средствами, накладно и нерационально.
Суть WebSphere Message Broker (который ныне IBM Integration Bus) в том, чтобы не писать в явном виде программный код. И при этом выполнять задачу интеграции приложений по разным протоколам/форматам/маршрутам.
Есть знания Java и XSL — отлично, там есть и Java Compute Node и XML Transformation Node.
Можно работать с WebSphere Message Broker и не знать что такое ESQL.
Да и если понадобится ESQL, он не особо отличается от PL/SQL или SQL/PL, язык простой, зная SQL и прочитав хотя бы пару уроков можно быстро вникнуть в суть алгоритма. XSL-шаблоны освоить по-моему сильно сложнее.
Много ли продуктов дают возможность принимать информацию практически из любого источника (MQ, JMS, FTP, HTTP, WebService, SAP Adapter, Database, Mail и т.д. и т.п.), парсить содержимое, перенаправлять/преобразовывать/дополнять и т.д. и т.п. и, отдавать на выходе в не меньшем количестве вариантов? При этом, зачастую, можно вообще не написать ни строчки кода. ИМХО продукт очень и очень хорошо решает тот круг задач, для которых был создан.
как Вы себе представляете процесс разработки под такой сервер? Ждать порядка пяти минут, чтобы сделать один единственый тест — это накладно и неправильно. Если часть логики еще более-менее можно юнитами оттестировать локально без деплоя (отсюда кстати лихорадка по поводу TDD), а если я разрабатываю веб например на JSF, мне хочется видеть любое изменение сразу же…
Разрабатывать для WAS очень желательно и весьма удобно в Rational Application Developer.
В нем есть встроенные средства для публикации изменений на сервер приложений (локальный или удаленный) через интерфейсы RMI и SOAP. При этом публикация может происходить автоматически (после сохранения изменений) или вручную (по нажатию кнопки Publish). При этом, в случае удаленного сервера генерируется дельта-файл, содержащий изменения, а в случае локального — может просто посылаться сигнал перечитать конфигурацию. Задержки при этом — минимальные.
Работая в RAD с локальным сервером приложений и меняя свое приложение я моментально могу посмотреть результат в браузере, не нажимая ни одной кнопки, кроме «Сохранить». Да, иногда бывают случаи (например при изменении binding), когда сервер не подхватывает изменения, в таком случае из среды разработки требуется выполнить установку/удаление приложения.
Относительно недавно аналогичный функционал стал доступен для среды Eclipse, о чем я уже писал выше.
Это теоретически. На практике при штатно работающем сервере перезапускать узлы никогда не требуется. А вот когда требуется задеплоить новую версию приложения на все ноды, от этого никакой кластер не спасает. У WAS типа есть фича, что-то вроде инкрементального деплоя (Update), но реально это никогда не работало, и очень геморно юзалось. Поэтому деполют всегда по-старинке: undeploy-deploy в пять часов утра. Можно конечно вручную деплоить поотдельности на оба узла, и настроить для этого балансер, но лень возиться.
При разворачивании новых версий приложения я знаю следующую практику:
1. Новая версия разворачивается с другим именем, содержащим номер версии в остановленном состоянии.
2. Останавливается существующая версия приложения.
3. Запускается новая версия приложения.
4. Если с новой версией что-то «не так», новая версия останавливается, предыдущая — запускается.
Все работает, все довольны. Простой — минимален.
В том-то и дело, что это реально не нужно. Если ваше приложение требует что-нибудь больше, чем Tomcat+Spring — это неправильное приложение, которое делает неправильный мед. Хотя это уже тема не столько Websphere сколько вообще инфраструктуры JEE. Сегодня никому нафиг эти тяжелые сервера не нужны с кучей непонятного и неудобоваримого API. Все это можно использовать при необходимости и вне JEE контейнера.
Как говорит IBM — It depends…
То что до этого делалось — это тихий ужас: Websphere Portal, Websphere Business Integration Platform, Websphere Process Server, Websphere Message Broker, Websphere MQ. Одно приятное исключение — DB2
Из этой группы я бы однозначно исключил Websphere Message Broker и Websphere MQ.
Эти два продукта, особенно MQ, это (ИМХО) одни из лучших, как внутри IBM, так и каждый в своем классе.
PS: К сожалению не смогу отвечать на комментарии до вечера (20:00 МСК), тк буду далеко от интернета.
Который раз слышу про «долгий старт». Насколько он долгий?
WebSphere Application Server позиционируется как серверный продукт, а сервера часто перегружать не принято. Т.е. время загрузки в пределах до 5 минут не является принципиальным моментом. Типичное время запуска порядка 1-2 минут, в зависимости от количества приложений.
Если нужна 100% доступность — нужно разворачивать кластер (Network Deployment), в нем перезапуск любого из узлов является прозрачным для конечных пользователей, за счет избыточности узлов.
«Прожорливость» была актуальна для ветки 6.x, в ветке 7.x и 8.x много чего делалось с точки зрения оптимизации. Более детальный разговор требует фактов и цифр.
Насчет WebSphere Portal — 100% согласен, продукт неудачный (ИМХО). С Process Server не сталкивался.
Для разработки под WAS есть:
— Rational Application Developer (платный продукт)
— Eclipse + «IBM WebSphere Application Server Developer Tools for Eclipse». (бесплатный продукт).
В сервер встроено много всякого добра, для обеспечения защиты/шифрования, отказоустойчивости, ведения журналов и т.п. вещей. Если все это «добро» в проекте не используется, то вопрос к правильности выбора платформы для проекта.
Liberty Profile — потенциально очень интересное решение. Максимально облегченный профиль, который легко «заточить» под свое приложение и поставлять весь комплект как единое целое.
Наиболее подходящ (ИМХО) для разработки новых приложений. При этом, то, что сделано для LP, с высокой вероятностью (говорю про вероятность, т.к. официальных гарантий от IBM не встречал) будет работать и на полном профиле того же уровня.
Насколько часто и по каким причинам нужно перезапускать сервер приложений в процессе разработки самих приложений?
Далеко не каждое изменение конфигурации сервера требует его перезапуска.
А если меняется само приложение — то обычно, максимум это нужно выполнить Uninstall/Install.
Подчеркиваю «обычно», поэтому и любопытны случаи, требующие частого перезапуска сервера приложений.
Возможно, я просто не сталкиваюсь с такими ситуациями.
Системы на IBM WAS нормально проходят аудит, что говорит о том, что «проблема» так или иначе решаема.
В статьях по приведенным выше ссылкам это тоже описано.
PS: А зачем «пользователю» доступ на чтение к файлам конфигурации сервера приложений?
Вот навксидку выдержка для Apache Tomcat: Why are plain text passwords in the config files?
В принципе, можно встроить свой код шифрования паролей, «точка входа» предусмотрена.
Пруф: Enabling custom password encryption
В версии 8.5 (Liberty Profile) появилась возможность «из коробки» кодировать пароли в режиме aes и hash.
Пруф: securityUtility command.
Насколько я понимаю, позиция IBM такова, что кодирование пароля не особо повышает защищенность, если есть возможность доступа к файловой системе сервера.
Статьи на эту тему:
The limits to protection through password encryption.
Comment lines: Encrypting WebSphere Application Server system passwords — if you insist.
Выполнялись ли в этой конфигурации нагрузочные тесты с непрерывной подачей платежных документов?
Т.е. возможность оплаты «проездных» обещается, но в настоящий момент отсутствует.
Такая реализация есть и в архиве slf4j-nop-*.jar. Подключение этого архива означает «Сознательное» блокирование вывода SLF4J.
Однако, если не найдена ни одна реализация, то будут использованы классы org.slf4j.helpers.NOPLoggerFactory, org.slf4j.helpers.NOPLogger и org.slf4j.helpers.NOPMDCAdapter, которые находятся в архиве slf4j-api-*.jar.
Это дает основной программе возможность работать, не сваливаясь по ClassNotFoundException.
Еще одна выдержка из документации: Failed to load class org.slf4j.impl.StaticLoggerBinder
Плюсы:
— если оператор логгирования не срабатывает (выключен соотв. уровень), то не тратится время на обращение к объектам, значения которых должны быть подставлены в тело сообщения.
— текст сообщения всегда идет одной строкой.
Пример:
Поправка по тексту статьи:
Начиная с версии 1.6, если не найдена ни одна реализация, то произойдет переключение на режим «no operation», но работать будет! Это написано в руководстве, второй абзац.
Gemini — поиск и удаление дубликатов файлов, использую в основном для фотографий.
Xee3 — просмотр фотографий.
NoMachine for Mac OS X — удаленный доступ с любой платформы.
Trim Enabler — включение функции Trim для любых SSD-дисков.
MPlayerX — проигрыватель видеофайлов.
А можно поподробнее, про какую конфигурацию кластера DB2 идет речь? Database Partitioning Feature или pureScale? Про «загнулась» тоже интересны подробности.
Плюсы плеера:
+ Управление с одного места, с пульта медиаплеера.
+ Телевизор автоматически переключается в режим 3D, при выборе 3D-режима на плеере.
+ Плеер умеет корректно отображать свое экранное меню в режиме 3D.
+ Плеер умеет проигрывать BD3D-образы (ISO или распакованный), правда без меню (BD-Lite).
+ Компьютер не занят во время воспроизведения фильма.
Ну и зря вы так уверены в этом. В MQ Explorer это есть. И заголовки можно посмотреть, и сообщение отображается и текстом и HEX-дампом.
Для загрузки/выгрузки сообщений можно и нужно пользоваться утилитой MO03, которая доступна на страничке WebSphere MQ — SupportPacs by Product аж с 2005 года!
Оно четко выполняет свою функцию — отправить тестовое сообщение. Если нужно специфичное форматирование и заполнение спец. заголовков — есть IH03(RFHUtil). Он, кстати, тоже позволяет сохранять сообщения на диск и читать их с диска.
Т.е. у Вас все таки есть какие-то претензии к основному функционалу (доставка сообщений), стабильности, производительности и отказоустойчивости этого продукта (IBM WebSphere MQ)? Если есть, озвучьте пожалуйста. Я пока не увидел ни одной. Он теряет сообщения? Не справляется с нагрузкой? Не реализует заявленные свойства? Есть проблемы при работе через какие-то API?
В чем проявляется его «сырость», кроме того факта что лично вам с ним «неудобно»? И если Вам при работе с этим продуктом было неудобно и непонятно, Вы (или Ваша компания) открыли отчет о проблеме (PMR) в IBM? Попросили поддержки и помощи в их решении?
Озвученное выше выглядит так, как будто Вы продукт «пощупали» мимоходом, даже не прочитав толком документацию, не познакомившись с архитектурой и особенностями. И, кроме того, даете оценку продукта в общем, не указывая версию/платформу, основываясь на мнении N-лет давности. А все меняется, что-то быстрее, что-то медленнее, но — меняется.
Пользуюсь, практически каждый день.
Работаю удаленно с менеджерами на Windows, Linux, z/OS.
Действия для подключения к удаленному менеджеру (MQ Explorer V 7.5, который умеет подключатся к менеджерам версии 6.0 и выше):
1. Запустить MQ Explorer.
2. Щелкнуть правой клавишей мышки на разделе Queue Managers
3. Выбрать пункт «Add Remote Queue Manager»
4. Ввести имя менеджера, к которому нужно подключиться. Поле: «Queue Manager Name»
5. Выбрать опцию «Connect Directly».
6. Нажать Next.
7. Ввести параметры соединения:
«Host Name or IP Address» — DNS-имя или IP-адрес сервера
«Port number» — номер порта TCP/IP
«Server-connection channel» — имя канала, через который будет выполняться подключение
8. Нажать Next.
9. Нажать Next.
10. Поставить галку «Enable user identification»
После этого ввести имя пользователя и пароль, которые существуют на сервере MQ.
Поле «Userid» и кнопка «Enter password»
11. Нажать Finish.
Собственно на этом все, можно пользоваться.
Это правда «нереально сложно»?
Похоже, что ваше знакомство состоялось с весьма старыми версиями этих продуктов и как то «не сложилось».
Современные версии продуктов IBM WebSphere MQ, IBM WebSphere Message Broker, IBM WebSphere Application Server и инструментов для работы с ними достаточно приятны в «общении», ИМХО конечно же.
Да, там не все и не всегда «интуитивно понятно». Но, есть документация, которая доступна публично, и легко гуглится, есть форумы, есть тех.поддержка, которая отвечает на самые разные вопросы.
А вы точно про IBM WebSphere MQ? Если да то какой версии?
Надежный, кроссплатформенный продукт для быстрой и гарантированной доставки приложений.
При этом, с единым интерфейсом программирования для всех платформ.
При этом с библиотеками для очень многих языков программирования.
Для Java есть или базовые классы MQ, или JMS.
JMS-интерфейс там вполне стандартен, в актуальных версиях является стандартным JCA-адаптером. Те нормально (без шаманств) встраивается в сервера, поддерживающие спецификацию JCA.
В версии 6.x были проблемы с производительностью определенных JMS-операций. Так в версии 7.x перенесли выполнение этих операций с JMS-библиотек на серверную часть MQ. Т.е. современный WebSphere MQ весьма неплохо оптимизирован для работы с JMS-интерфейсом.
И опять это явно не про тот WebSphere MQ, с которым я знаком.
GUI инструмент, который называется WebSphere MQ Explorer, идет в комплекте уж точно с версии 5.3, про более ранние — не помню. Причем достаточно давно его можно скачать отдельно от серверной и клиентской части. Он бесплатен и весьма функционален. Есть доп. плагины для еще большего расширения функционала. И им же можно генерировать JNDI-описания для Java SE, если вдруг возникает такая необходимость.
Суть WebSphere Message Broker (который ныне IBM Integration Bus) в том, чтобы не писать в явном виде программный код. И при этом выполнять задачу интеграции приложений по разным протоколам/форматам/маршрутам.
Есть знания Java и XSL — отлично, там есть и Java Compute Node и XML Transformation Node.
Можно работать с WebSphere Message Broker и не знать что такое ESQL.
Да и если понадобится ESQL, он не особо отличается от PL/SQL или SQL/PL, язык простой, зная SQL и прочитав хотя бы пару уроков можно быстро вникнуть в суть алгоритма. XSL-шаблоны освоить по-моему сильно сложнее.
Много ли продуктов дают возможность принимать информацию практически из любого источника (MQ, JMS, FTP, HTTP, WebService, SAP Adapter, Database, Mail и т.д. и т.п.), парсить содержимое, перенаправлять/преобразовывать/дополнять и т.д. и т.п. и, отдавать на выходе в не меньшем количестве вариантов? При этом, зачастую, можно вообще не написать ни строчки кода. ИМХО продукт очень и очень хорошо решает тот круг задач, для которых был создан.
Разрабатывать для WAS очень желательно и весьма удобно в Rational Application Developer.
В нем есть встроенные средства для публикации изменений на сервер приложений (локальный или удаленный) через интерфейсы RMI и SOAP. При этом публикация может происходить автоматически (после сохранения изменений) или вручную (по нажатию кнопки Publish). При этом, в случае удаленного сервера генерируется дельта-файл, содержащий изменения, а в случае локального — может просто посылаться сигнал перечитать конфигурацию. Задержки при этом — минимальные.
Работая в RAD с локальным сервером приложений и меняя свое приложение я моментально могу посмотреть результат в браузере, не нажимая ни одной кнопки, кроме «Сохранить». Да, иногда бывают случаи (например при изменении binding), когда сервер не подхватывает изменения, в таком случае из среды разработки требуется выполнить установку/удаление приложения.
Относительно недавно аналогичный функционал стал доступен для среды Eclipse, о чем я уже писал выше.
При разворачивании новых версий приложения я знаю следующую практику:
1. Новая версия разворачивается с другим именем, содержащим номер версии в остановленном состоянии.
2. Останавливается существующая версия приложения.
3. Запускается новая версия приложения.
4. Если с новой версией что-то «не так», новая версия останавливается, предыдущая — запускается.
Все работает, все довольны. Простой — минимален.
Как говорит IBM — It depends…
Из этой группы я бы однозначно исключил Websphere Message Broker и Websphere MQ.
Эти два продукта, особенно MQ, это (ИМХО) одни из лучших, как внутри IBM, так и каждый в своем классе.
PS: К сожалению не смогу отвечать на комментарии до вечера (20:00 МСК), тк буду далеко от интернета.
Который раз слышу про «долгий старт». Насколько он долгий?
WebSphere Application Server позиционируется как серверный продукт, а сервера часто перегружать не принято. Т.е. время загрузки в пределах до 5 минут не является принципиальным моментом. Типичное время запуска порядка 1-2 минут, в зависимости от количества приложений.
Если нужна 100% доступность — нужно разворачивать кластер (Network Deployment), в нем перезапуск любого из узлов является прозрачным для конечных пользователей, за счет избыточности узлов.
«Прожорливость» была актуальна для ветки 6.x, в ветке 7.x и 8.x много чего делалось с точки зрения оптимизации. Более детальный разговор требует фактов и цифр.
Насчет WebSphere Portal — 100% согласен, продукт неудачный (ИМХО). С Process Server не сталкивался.
Для разработки под WAS есть:
— Rational Application Developer (платный продукт)
— Eclipse + «IBM WebSphere Application Server Developer Tools for Eclipse». (бесплатный продукт).
В сервер встроено много всякого добра, для обеспечения защиты/шифрования, отказоустойчивости, ведения журналов и т.п. вещей. Если все это «добро» в проекте не используется, то вопрос к правильности выбора платформы для проекта.
Наиболее подходящ (ИМХО) для разработки новых приложений. При этом, то, что сделано для LP, с высокой вероятностью (говорю про вероятность, т.к. официальных гарантий от IBM не встречал) будет работать и на полном профиле того же уровня.
Далеко не каждое изменение конфигурации сервера требует его перезапуска.
А если меняется само приложение — то обычно, максимум это нужно выполнить Uninstall/Install.
Подчеркиваю «обычно», поэтому и любопытны случаи, требующие частого перезапуска сервера приложений.
Возможно, я просто не сталкиваюсь с такими ситуациями.