Кто подскажет какая архитектура лучше?

Вместо обычных сервлетов все-же используй Jakarta Struts, это не сильно скажется на производительности, а вот на организации кода и общей архитектуре - существенно.
А насчет бобов у меня есть сомнения. http://www.javable.com/javaworld/12_01/01/, вот хорошая статья. По мне, все же, если структура БД и логика серверной части проста и не планируется ее значительные переработки в будущем, и критично важна производительность (особенно, если инфраструктура не слишком мощная), то можно и без них обойтись будет. Но! - если вы сами пока точно не можете определиться с будущей сложностью, или уже предполагаете, что логика может усложняться - тогда я ЗА EJB.

Многие используют для етой цели WebServices и SOAP-протокол соответственно. WebService создавались с целью использования их для передачи XML-ок. Я несколько раз использовал WebService, но относительно производительности ничего конкретного сказать не могу, потому-что нагрузки били не большие.

Это Enterprise service bus, зачем мне EJB?

У меня вот такие требования:

- только https
- только XML

Но возможно будут разные destinations для разных XML(своеобразный mapping).

В Базу будем скорее всего только писать, читать врядли.

Jakarta Struts - зачем мне этот Web-framework. У меня не будет никаких GUI интерфейсов.
[INDENT]Многие используют для етой цели WebServices и SOAP-протокол соответственно. WebService создавались с целью использования их для передачи XML-ок. Я несколько раз использовал WebService, но относительно производительности ничего конкретного сказать не могу, потому-что нагрузки били не большие.[/INDENT]
Хорошое и разумное предложение! Но все таки WebServices не для передачи XML. А для вызовов методов (сервисов).

- А у меня набор больших документов (правила) в Word-e, описывающих XML запросы и их типы... (SOAP обертка тут не подойдет)!

Спасибо

Ну тогда юзай ESB.
Ето по-крайней мере более структурирований подход чем просто обичний сервлет.
Плюс, ESB дает возможнось создавать правила форвардинга реквеста базируясь на контенте (XML).
Есть разние реализации, не могу советовать конкретной реализации, так-как сам немного пробовал только BEA Aqua Logic Service Bus.

Я более подробно просмотрю ESB, но не уверен она потянет такие нагрузки...? Как считаете?!! Не уверен, в ней ведь куча не относящихся к моей задаче вещей есть, которые будут грузить сервер.

Ну что?!!! Я полагаю, что так и придется использовать HttpServlet с поддержкой SSL. Тогда вот встречные вопросы.

1) Как лучше использовать сервлеты -
- один сервлет на все запросу(это по умолчанию так сервлеты работают)
- один запрос на один сервлет (это делается через реализацию SingleThreadModel).

еще раз напомню, что у меня сервлеты будут как бы stateless(один запрос, один ответ, и все - не будет никаких сессий и состояний).

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

2) А вообще сервлеты можно распределить через кластер, есть у кого-нибудь опыт? Ведь моим сервлетам друг с другом общаться не нужно будет, и место у них - база данных.

3) А собственно, ведь для запуска Сервлетов, мне J2EE контейнер не нужен полноценных, можно обойтись Servlet контейнером, который определенно будет меньше есть. Так какой же контейнер использовать (на Tomcat же не серьезно для такого проекта)?

Всем благодарен! Спасибо

Относительно ESB: я не полностью знаю твою задачу, но исходя с того что ти написал, может ESB и пригодится если тебе нужно при разних даних разние действия делать - но хотя если у тебе флов одинаковий для всех запросов, то тогда юзай сервлет.

Относительно сервлетов: я би не использовал SingleThreadModel, потому-что у тебя сервлети будут і так stateless, и для сервлет контейнер будеть легче так роботать.

Относительно кластера: кластер тебе конечно очеть поможет, разгрузит нагрузку - поставь несколько машин и по 2-4 сервака на каждую. У тебя не будет проблем с распределением сервлета через кластер. Сдесь главная вишка следующая - нужно учесть, если сервак падает и запрос где-то посредине сервлета оборвалься, то кластер перенаправит етот запрос на другой сервак, то-исть нужно написать код так, что-би две одинакових записи в БД не попали.

Относительно сервера для кластера: мне тежело что-нибуть тебе подсказать, потому-что я юзал Tomcat и WebLogic. Конечно WebLogic намного круче, но он платний. Кластерность у него организована удобно. Относительно других серваков не знаю, может кто нибуть подскажет (или юзай Гугл).

[ATTACH]2223[/ATTACH]

Вот итоговая архитектура. Кто еще что добавит?

- Будет полагаю Spring + Spring JDBC + Servlet.

Но есть еще не решенные моменты:

1) Какой лучше библиотекой пользоваться для маппинга XML на Java Objects и обратно?

2) Чем воспользоваться для распределенного кеширования объектов из базы, которые я получу через Spring JDBC (они ведь не будут закешированны).

Всем благодарен! Спасибо