Вышел JBoss 5.0.0

Это опять нужно новые книжки по JBoss 5 покупать? Наверняка все поменяли снова, и все, что относилось к 4.2, в 5.0 будет работать по-другому?

А для чего он нужен? Нет, ну серьезно, покажите задачи, которые без него сложно или невозможно решить? Зачем такой монстр нужен - непонятно.

>А для чего он нужен? Нет, ну серьезно, покажите задачи, которые без него сложно или невозможно решить? Зачем такой монстр нужен - непонятно.вы наверное не в курсе сколько стоят weblogic и websphere

> А для чего он нужен? Нет, ну серьезно, покажите задачи, которые без него сложно или невозможно решить? Зачем такой монстр нужен - непонятно.

Он не такой уж толстый по сравнению с. Да и когда приложение огромно и томкат может превратится в монстра.

- Зачем нужен самолет?
- Как зачем? Чтобы не покупать космический корабль!

Между тем вопрос был вполне конкретный: решение каких задач без него или его аналогов неэффективно?

>Между тем вопрос был вполне конкретный: решение каких задач без него или его аналогов неэффективно?

Ну это типа ынтырпрайз... А в ынтырпразе все на java лабают вроде как...

> Между тем вопрос был вполне конкретный: решение каких задач без него или его аналогов неэффективно?

Ну нарисуй вебсервисы на коленке.

> Ну нарисуй вебсервисы на коленке.

Как например ютуб или гмайл, такие? :)

>Между тем вопрос был вполне конкретный: решение каких задач без него или его аналогов неэффективно?

Короткий ответ: решение задач, которые используют почти все или многие его возможности, без него неэффективно. Почему? Потому что при необходимости использования такого количества возможностей (что диктуется объемом функционала приложений, которые на нем будут развернуты) делать все "from scratch" - это значит заново написать свой JBoss. Такой ответ просто вытекает после недолгих логических размышлений. Создается впечатление, что автор задал вопрос не ответа ради, а ради травли.

>Как например ютуб или гмайл, такие? :)

Нет не такие - а которые соответствуют спецификациям OASIS.

Приведи пример известных сервисов, соответствующих этой спецификации.

> Приведи пример известных сервисов, соответствующих этой спецификации.

Блин, чувак, ты даже не знаешь, что такое веб сервисы, заканчивай уже с дурацкими вопросами, как школьник выглядишь.

Твою мать, тут серьезные дядьки чатятся на лоре, а я со своими школьными проблемами. Извините :)

ps хотел сделать ошибки, чтобы соответствовать спецификации SCHOOLBOY, но Grammar Nazi, сидящий во мне, не позволил, извините еще раз :)

> Короткий ответ: решение задач, которые используют почти все или многие его возможности, без него неэффективно. Почему? Потому что при необходимости использования такого количества возможностей (что диктуется объемом функционала приложений, которые на нем будут развернуты) делать все "from scratch" - это значит заново написать свой JBoss. Такой ответ просто вытекает после недолгих логических размышлений. Создается впечатление, что автор задал вопрос не ответа ради, а ради травли.

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

Я вижу желательным применение таких продуктов как жбосс только в том случае, если необходимо произвести интеграцию разнообразных сервисов написанных на жабе. А то был у нас один программист - всё порывался написать с использованием жбосса простой гейт база <-> xml, причём обязательно с кастомным форматом xmlя.

То есть примеров у тебя нет?

Любая распределённая система обслуживания.

Впрочем, есть более легковесные и функциональные аналоги, из которых можно собрать что нужно.

Всё это можно реализовать на PHP.

Конечно можно. Даже на С можно.

> Любая распределённая система обслуживания.

А зачем там именно (soap) веб-сервисы?

> покажите мне задачу, которая использовала бы все возможности жбосса ? со всякими там друлсами и прочим.

Ну приходи, покажу на моем мониторе ;). Линк не дам, т.к. система пропиетарная, я связан NDAs. Кроме JBoss, кстати говоря, мы поддерживаем деплоймент и на куда более толстые вещицы: Weblogic и Websphere.

> Я вижу желательным применение таких продуктов как жбосс только в том случае, если необходимо произвести интеграцию разнообразных сервисов написанных на жабе.

Совершенно верно. Особенно когда разрабатывается целый сьют близких по бизнесу приложений.

> А то был у нас один программист - всё порывался написать с использованием жбосса простой гейт база <-> xml, причём обязательно с кастомным форматом xmlя.

Так а причем тут ваш малоопытный программист с гигантоманией? То что он не видит простых проектных решений, по большей части это его проблема.

Ну действительно, какая например система обслуживания - ссылку в студию.

А то тут многие несут чуш, а просто пример показать не могут.

> Впрочем, есть более легковесные и функциональные аналоги, из которых можно собрать что нужно.

Ага, да-да. Пока ты будешь собирать и рваться на подводных камнях каждого такого аналога, твой клиент потеряте бизнес ;) Да уж, аналитики лора всегда славились куда большим профессионализмом, чем аналитики редхата, оракле и айбиэм. ;)

> Ну действительно, какая например система обслуживания - ссылку в студию.

Ну вот дам я тебе сейчас ссылку на пропиетарную систему. И как ты проверишь, что она действительно использует все то что идет с джбоссом?

Тогда зачем?

Чтобы даже без единого коннекта, funambol отжирал все ресурсы сервера?

>вы наверное не в курсе сколько стоят weblogic и websphere

а про веб сферу можно сказать что ко всему прочему она ещё и более тормознутая и сложнее конфигурируемая чем jboss.

>Впрочем, есть более легковесные и функциональные аналоги, из которых можно собрать что нужно

и какой же из java application server'ов легче жбосса?

http://uptime.netcraft.com/up/graph?site=odnoklassniki.ru
- правда, это Resin, а не JBoss.

>и какой же из java application server'ов легче жбосса?

Apache Geronimo, GlassFish?

И меня интересует вопрос на кой нужен jboss? тут что-то про интеграцию и распределённые системы говорят, для конкретики... есть такая книга распределённые системы принципы и парадигмы за авторством Таненбаума.

Достаточно номера страницы, на которой описана такая система, которая с jboss просто на раз два три решается.

> а про веб сферу можно сказать что ко всему прочему она ещё и более тормознутая и сложнее конфигурируемая чем jboss.

Это железо у вас тормознутое, чтобы крутить такую махину.

> Ага, да-да. Пока ты будешь собирать и рваться на подводных камнях каждого такого аналога, твой клиент потеряте бизнес

На чистом J2EE очень тяжело что-либо реальное написать, значит придётся завязываться на JBoss/Websphere/anything else. А где подводных камней меньше, ещё вопрос.

> Apache Geronimo, GlassFish?

Не сказал бы, что geronimo уже production ready. GlassFish vs JBoss - тоже достаточно спорно.

Сказали же сто раз уже. В application server-е есть куча вещей, многие из которых нужны стандартным системам обслуживания. Он соответствует определённым стандартам, есть куча специалистов, которые знают как с ним работать, есть техподдержка. Бизнесам это нравится, они не любят лишние риски, связанные с тем, что петя будет вместо недели два месяца реализовывать распределённые транзакции, и полгода отлавливать баги.

> есть такая книга распределённые системы принципы и парадигмы за авторством Таненбаума.

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

>что такое веб сервисы
я тоже не знаю. Это программа оказывающая услуги и использующая для своего функционирования систему гипертекста? ну это хотя бы программа?

Для интеграции с другими системами.

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

Цитирую википедию:

Веб-служба, веб-сервис (англ. web service) — программная система, идентифицируемая строкой URI, чьи общедоступные интерфейсы определены на языке XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью интернет-протоколов. Веб-служба является единицей модульности при использовании сервисно-ориентированной архитектуры приложения.

>server-е есть куча вещей, многие из которых нужны стандартным системам обслуживания.
это технологические преимущества или просто это удобно продавать?

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

А я между прочим и не говорил, что вообщем нет таких систем, которые нельзя реализовать без jboss, причем обратное говорил точно. У таненбаума там все достаточно теоретично, практика оказывает все же немного другой. Да и не стоит воспринимать подобные книги как догму. Не все так просто.

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

> это технологические преимущества или просто это удобно продавать?

Разуй глаза и открой для себя, что джбосс является полностью свободным сервером. редхат конечно продает на него поддержку, но девелоперской конторе вполне можно без нее обойтись своими силами.

про glassfish не сказал бы что легче, да и знакомые что то писавшие под него говорили что лучше бы они использовали jboss

>Разуй глаза и открой для себя, что джбосс является полностью свободным сервером.

продают же не jboss, а системы на нём построенные

>С технологической точки зрения это набор полезных библиотек и фреймворков, которые, к тому же, многие знают.

т.е. они не лучше и не хуже, просто их многие знают? ну да если бы я не сам делал программу, то выбрал бы эти технологии :)

> тут что-то про интеграцию и распределённые системы говорят, для конкретики...

Конкретика: JBoss Portal+Alfresco+Petaho. Ты можешь использовать отдельно аналог Portal (это посути Web CMS), отдельно аналог Alfresco (CMS), отдельно аналог Petaho (ERP), но, зачем? Через JBoss ты всё это имеешь на одной платформе с централизованным доступом и разграничением прав, с интеграцией одного в другое, с единообразным интерфейсом и лёгкостью масштабирования и развёртывания.

Достаточно внятный пример? Попробуйте обойтись без сервера приложений для решения подобной задачи объединения разнородных программ в одном контейнере. Нет, конечно, unix-way рулит, когда из разных кубиков ты строишь себе систему на базе ядра Linux, но уровень кубиков несколько ниже, и решения по отдельности разрабатываются слегка сложнее.

> продают же не jboss, а системы на нём построенные

Не надо сворачивать на совсем другую похожую словами тему. Изначально обсуждалась именно ценность апп-сервера как такового, а не систем, которые можно на нем строить. Системы во-первых могут очень разными в стоимости и во-вторых кастомеру в общем пофиг джбосс там али нет, главное чтобы это ему дороже не обошлось. Вот о чем речь была:

>>> server-е есть куча вещей, многие из которых нужны стандартным системам обслуживания. >> это технологические преимущества или просто это удобно продавать?

Так что "удобно продавать" вообще не аргумент в частоности для джбосса. Для веблоджика, вебсферы - да, но не для джбосса.

>Достаточно внятный пример? Попробуйте обойтись без сервера приложений для решения подобной задачи объединения разнородных программ в одном контейнере.

Всё это, конечно, хорошо для нескольких разнородных JEE-приложений, выполняющихся под управлением одного app-сервера. Но это будет хорошо только на узлах локальной сети предприятия, но далеко не в Web, где царствует "мусорная" идеология "сляпанных" по-быстрому CGI-сервисов и всяческих субтехнологий, использующих Common Gateway Interface в общем смысле этой аббревиатуры.

Как быть с однородными Web-технологиями?
К примеру, почему не популярны хостинги простых JSP-приложений, по функциональности сопоставимых с LAMP? Ведь для JSP не нужен весь стэк JEE-библиотек и разворачивается оно легко и непринуждённо (кстати, без Apache можно обойтись — одним лишь Tomcat); опять же, заявлена кластеризация и балансировка нагрузки. Для PHP: обязательно наличие Apache Server, подключаемого модуля интерпретатора, плюс разные настройки и конфигурация для того и другого, плюс программные фреймворки и библиотеки, заточенные под определённые задачи. Тем не менее, PHP популярнее JSP в десятки раз (если кто из пользователей вообще слышал о JSP).

> Но это будет хорошо только на узлах локальной сети предприятия, но далеко не в Web

Так а Java никогда и не позиционировалась вот так вот именно для веб, как, например, тот же PHP. Java для поддержки большого бизнеса ;).

> К примеру, почему не популярны хостинги простых JSP-приложений, по функциональности сопоставимых с LAMP? Ведь для JSP не нужен весь стэк JEE-библиотек и разворачивается оно легко и непринуждённо (кстати, без Apache можно обойтись — одним лишь Tomcat); опять же, заявлена кластеризация и балансировка нагрузки. Для PHP: обязательно наличие Apache Server, подключаемого модуля интерпретатора, плюс разные настройки и конфигурация для того и другого, плюс программные фреймворки и библиотеки, заточенные под определённые задачи. Тем не менее, PHP популярнее JSP в десятки раз (если кто из пользователей вообще слышал о JSP).

Хостинги не популярны и PHP популярнее JSP, т.к. на PHP можно писать особо и не изучая программирование как таковое. Вот и пишут, хотят выставлять свои сайтики в интернет, а если есть спрос на хостинг, то есть и предложение. Хотя и на PHP можно писать хорошо и грамотно ;)

Tomcat без Apache - это кстати тоже не очень правильно, Apache поди побыстрей статику отдает, да и для балансировки и правильной работы в кластере (репликация сессии и т.п.) он таки нужен ;). Так что фронт-енд нужен, а лучше еще и с кешем.

Да, для JSP не нужен весь стэк JEE-библиотек. Но и используя только JSP тоже очень неправильно писать. JSP - это только view из MVC. Можно написать простенький свой MVC как это JSP Model 2 предлагает, а можно использовать уже готовый Struts. А можно вообще компонентый подход использовать: JSF. И вот так добавлять, добавлять либы - в итоге и получится большой JBoss :)

Тоже самое говорят про битрикс. Стандарты, техподдержка, петя и т.д.

А про риски я могу сказать только одно. Риск, это когда ты шел на работу, а попал в больницу. То есть по пути ты рисковал. Но когда речь идет про яву, томкат, джбос и т.п. рисков никаких нет ибо хуже уже некуда...