Xpages - а какой Background?

Привет,
начал я знакомиться с xPages. Могу сказать, что это первое, что сделало IBM начиная с версии 6, что реально радует (не считая вебсервисов)... только подобные фреймворки уже давно не новость...

Вопрос не в этом. Теперь у нас есть механизм построения интерфейса - xPages. А кто будет исполнять бизнес логику? LS с xPages, насколько я знаю, не очень хорошо коннектиться, морально устарел и страдает проблемами утечки памяти. Java - память утекает, насколько я понимаю, еще хлеще.
И что выбирать?

Последнее замечание... xPages действительно хорошая технология. Но тут возникает впрос - а зачем вообще тогда нужен LN? Можно взять application сервер, Java MVC фреймворк и сделать тоже приложение... на этот впорос можно не отвечать

пс
Все любят кричать про репликацию. С развитием Веб это преимущество уже никому не нужно

0

fedotxxl

Все любят кричать про репликацию. С развитием Веб это преимущество уже никому не нужно

как-то громковато сказано

Простой пример:
1) Есть мега рабочий сервер в банке по клиентам и их считам и всем финансам
2) Внешний сервер посредством репликации тянет к себе минимум данных - карточку клиента и тоговую сумму, дабы клиент авторизируясь видел сумму

Можно конечно и без репликации, но так же проще и безопасно
Внешний сервак видит внутренний только по 1350 с наружи на него не пробиться

0

Сообщение от ToxaRat Есть мега рабочий сервер в банке по клиентам и их считам и всем финансам

Тот кто сделает это в банке на Домино - очень глупо поступит

Сообщение от ToxaRat Можно конечно и без репликации, но так же проще и безопасно

;)

Сообщение от ToxaRat Внешний сервак видит внутренний только по 1350 с наружи на него не пробиться

:lool:

0

Давай не начинать очередную тему что лучше =)

Мне интересно, на чем вы бы реализовали бизнес логику, если UI - xPages?

Добавлено:

Тот кто сделает это в банке на Домино - очень глупо поступит

Кстати, я согласен. Я видел на LN разные системы - HR, финансы... они заранее не могли удовлетворять требованиям пользователя, т.к. платформа не та... но опять же это не в ту степь

0

Сообщение от fedotxxl Мне интересно, на чем вы бы реализовали бизнес логику, если UI - xPages?

Где-то раньше же писали, что JS & Java. Что еще нужно?

0

Сообщение от fedotxxl Мне интересно, на чем вы бы реализовали бизнес логику, если UI - xPages?

Сейчас я бы взял какой-нить современный Java Web фреймворк, и написал бы все на нем. Если мне заказчиком поставлена задача использовать именно домино для хранения данных, то я бы сделал отдельный слой DAO для домино. Все это можно заставить вертеться на самом домино сервере, но можно поставить рядом томкат и не парится.
Минусы такого решения - дольше делать, плюсы - можно в любой момент избавится от домино вообще, веб будет работать быстрее.
Если проект большой, то баги и кривизна лотуса убьет все преемущества по времени, так что ява это однозначный виннер

Но если не отвлекаться от темы топика, то насколько я понял, IBM-цы предлагают использовать SSJS. Вроде бы они сделали дополнительное яваскриптовое API, которое очень близко к базовому лотусскриптовому/явовскому. Если не для бизнес-логики его использовать, то это апи вообще нафиг не нужно

Кстати, при всей крутизне XPages, писать используя это яваскриптовое апи так же неудобно как раньше (до 8ки) было использовать яву в лотус дизайнере. Так что делайте выводы.

0

Сообщение от K-Fire можно в любой момент избавится от домино вообще

какой ты злой! я от тебя такого не ожидааал!

0

то я бы сделал отдельный слой DAO для домино.

С этой минуты по-подробнее? Интересна тема вынесения всего функционала на tomcat с возможностью доступа к объектам LN, валидации доступа к документам и т.д.

Предположим, что UI оставляем на LN, backGround - на Tomcat через вызовы web-serviceов. Вопрос - можно ли сторонней программой получить сессию и управлять данных LN при помощи Java? Насколько я помню, в этом направлении были проблемы

Нашел инфу по теме
http://www.javable.com/docs/articles/domino/
http://www.ibm.com/developerworks/lotus/li...ava_access_pt1/
http://www.ibm.com/developerworks/lotus/li...-Java_access_2/
Running a Java program - help дизайнера

Я так понял, что нужно двигаться в сторону технологии corba. Кто с ней работал?) Как быстро, надежно, имеет ли смысл?

0

Сообщение от fedotxxl Мне интересно, на чем вы бы реализовали бизнес логику, если UI - xPages?

backing beans. без вариантов. http://www.mindoo.com/web/blog.nsf/dx/16.0...tm?opendocument

0

Сообщение от turumbay backing beans. без вариантов. http://www.mindoo.com/web/blog.nsf/dx/16.0...tm?opendocument

не устану повторять: xpages - это не только UI. Это киллер-фича, позволяющая отказаца от агентов и веб-сервисов при разработке под тонкого клиента. Ее можно использовать как замену традиционных сервлетов. И для меня xpage в первую очередь - это именно средство разработки серверной части приложения. А вот как раз UI морду можно рисовать и без них. dojo идет в комплекте, подключить любой другой js фреймворк( jquery , extjs ) - тоже не проблема

0

Таак... становится интересно

не устану повторять: xpages - это не только UI. Это киллер-фича, позволяющая отказаца от агентов и веб-сервисов при разработке под тонкого клиента. Ее можно использовать как замену традиционных сервлетов. И для меня xpage в первую очередь - это именно средство разработки серверной части приложения. А вот как раз UI морду можно рисовать и без них. dojo идет в комплекте, подключить любой другой js фреймворк( jquery , extjs ) - тоже не проблема

1. Кто будет исполнять код, если xPages исполняются на клиенте? Клиент пользователя? Это медленно...
2. dojo идет в комплекте, подключить любой другой js фреймворк( jquery , extjs ) - вы пробовали?
3. Как обстоят дела с большими нагрузками? Работа с памятью, утечка памяти?

Т.е. получается, что xPages - Java MVC по лотусовому?

0

Пару ссылочек:

http://www-10.lotus.com/ldd/ddwiki.nsf/dx/...logic_xpage.htm

http://www-10.lotus.com/ldd/ddwiki.nsf/dx/...gration_rdb.htm

0

Сообщение от fedotxxl 1. Кто будет исполнять код, если xPages исполняются на клиенте? Клиент пользователя? Это медленно...

xpages на клиенте пока не очень здорово работают из-за недоделанной интеграции java.policy и ecl.
А насчет медленно - это опять же зависит от кода. Это обычный java-код, врожденной расположенности к тормозам нету. Общение с domino идет как обычно - через nrpc, так что скорость сравнима с обычным(ls) кодом на клиенте. Основной затык будет при первом обращении, когда клиент будет собирать и деплоить сервлет на локал. Но я бы не стал заранее утверждать что все будет тормозить.

Сообщение от fedotxxl 2. dojo идет в комплекте, подключить любой другой js фреймворк( jquery , extjs ) - вы пробовали?

да. юзал jquery. клал файлы в ресурсы базы. а можно положить рядом с dojo.

Сообщение от fedotxxl 3. Как обстоят дела с большими нагрузками? Работа с памятью, утечка памяти?

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

Сообщение от fedotxxl Т.е. получается, что xPages - Java MVC по лотусовому?

нет. это в чистом виде Java Server Faces + набор компонент для домино.

0

Сообщение от fedotxxl С этой минуты по-подробнее? Интересна тема вынесения всего функционала на tomcat с возможностью доступа к объектам LN, валидации доступа к документам и т.д. Предположим, что UI оставляем на LN, backGround - на Tomcat через вызовы web-serviceов. Вопрос - можно ли сторонней программой получить сессию и управлять данных LN при помощи Java? Насколько я помню, в этом направлении были проблемы

Не, не совсем так. Tomcat используем для UI, и для бизнес логики. В качестве СУБД - Домино. Получить доступ к Java API из томката не вижу никакой проблемы (хотя может и придется поприседать чуть-чуть). По-моему тут несколько тем было о том как вызывать лотусовый Java API из внешних программ.

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

Хотя сразу не подумал об одной проблеме - аутентификация лотус-пользователей на томкате. Но думаю через SSO это можно решить.

0

K-Fire
Думаю, ты столкнулся со сложностью реализации UI на LN... а вот я столкнулся с тем, что при больших нагрузках на сервер из-за сложной бизнес логики, сервер падает. Поэтому мне кажется логичнее перести работу по бизнес логике на внешний Application сервер, а UI оставить в LN - пользователи даже знать не будут о нашем Tomcat + можно работать из толстого клиента + аудентифицировать нужно всего-лишь одного пользователя

Вопрос тут такой:
1. Как бысто будет работать?
2. Какие тут подводные ками?

Теперь по поводу beans и xPages - это интересный вариант, который нужно развивать. Но как реализовать агенты по-расписанию, используя beans? От них отказаться не получится?

0

Почитал я про утетки памяти в лотусовой Java. В итоге стало ясно, что вынесение логики на выделенный сервер проблемы с утечкой памяти не решит.... возникла такая безумная идея:
1. Источником информации делаем sql базу данных
2. Tomcat работает с нашей sql базой ничего не зная о LN
3. Для отображения информации используем xPages, которые берут инфу из beana, который забирает ее через jdbc из базы SQL

Безумно... будет работать?

0

fedotxxl, а на кой тогда вообще Лотус?

0

Yakov
Для заказчика ничего не поменялось - пользователь работает в клиенте LN...
Плюс такого решения - можно безболезненно полностью убрать LN

0

Федот, ты рождаешь идеи от которых у меня волосы на голове дыбом встают :ya_lamo:

Во-первых:
"Поэтому мне кажется логичнее перести работу по бизнес логике на внешний Application сервер, а UI оставить в LN - пользователи даже знать не будут о нашем Tomcat + можно работать из толстого клиента + аудентифицировать нужно всего-лишь одного пользователя"

Как ты себе представляешь бизнес-логику на иных платформах а UI в нотес? Стандартный лотусовый UI может работать только с домино. Java UI (который фактически SWT-плагин внутри лотусового клиента) - это извращение, XPages на клиенте - это те же яйца лотуса, только вид сбоку.
Если очень хочется что-то типа "XPages", то можно запускать в композитном приложении ембеддед браузер с полностью не лотусовым веб-приложением.
Но это откровенное издевательство над здравым смыслом.

Сообщение от fedotxxl Почитал я про утетки памяти в лотусовой Java. В итоге стало ясно, что вынесение логики на выделенный сервер проблемы с утечкой памяти не решит.... возникла такая безумная идея: 1. Источником информации делаем sql базу данных 2. Tomcat работает с нашей sql базой ничего не зная о LN

Томкат, Джетти, Джибосс, В*цензура*джик, Вебсфера... Это я так, на всякий случай, чтобы ты не подумал что томкатом все заканчивается :what?:

Сообщение от fedotxxl 3. Для отображения информации используем xPages, которые берут инфу из beana, который забирает ее через jdbc из базы SQL Безумно... будет работать?

Безумно, будет работать. Тут главное выбрать главную часть из этого предложения. А главная часть это не "будет работать" а "безумно"
Зачем в таком случае тебе вообще XPages? И тут приходим к тому что я изначально писал, что лотус в такой схеме вообще не нужен. Достаточно браузера. Он бесплатен, его не надо ставить, он быстро запускается. Аутентификацию можно сделать общую с виндовой, лотус опять в пролете.

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

0

K-Fire
У нас в стране рынок LN еще живой... проблема в том, что формочки, представления и LS уже в горле... UI устарел, backGround валит сервер. Java comunity огромное, поэтому технологии Java так и развиваются.

Кто сказал, что xPages в клиенте плохо работают? Я пока делал только вводные туториалы, но все нормально.

Зачем в таком случае тебе вообще XPages?

Заказчик в результате будет работать с удобным интерфейсов, в "защищенном" Lotusовом клиенте. В конце концов ничего не будет мешать реализовать UI просто на JSF или любой другой технологии.

Проще поставить вопрос так: зачем вообще делать приложения на LN?

Мне тема интересна, будет время - сваяю набросок.

Насколько я понял здесь есть два камня:
1. Придется ставить сторонние приложения (сервер приложений, базу)
2. Придется на каждую машину пользователя копировать определенные jarы...

В принципе жертвы, но если результат стоит того....

пс
xPages фактически делают из LN сервер приложений с MVC фреймворком, где за модель отвечает документы (которые кстати постарались закосить под SQL), представление - сами xPages, а контроллер - beanы и агенты (надеюсь я прав во всем этом =)). Вопрос такой: почему бы не использовать чистые Java MVC - JSF, JBoss Seam, GWT, Click, серверы приложений и SQL базы данных?

0