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

[alexlexa]

На этом изображении представлена планируемая архитектура будущего проекта. Нужно написать "что-то", что будет принимать XML фрагменты с одной стороны, обрабатывать их и в базу что-то совать, а затем эти XML конвертировать в другие XML(другого формата) и отправлять их дальше по другим адресам. И затем ждать ответа от них, снова переделывать формат, что-то писать в БД и отсылать тому от кого изначально пришел запрос. Своеобразный прокси нужно сделать.

Все должно работать на HTTPS. Держать нагрузку 300000 тысяч в день запросов или больше...

Кто что бы предложит?!!! Я пока вижу обычный сервлет, работающий по HTTPS.

Может кто-нибудь порекомендует использовать ESB или еще что-нибудь?

Заранее благодарен

 

[Kmet]

ESB это Enterprise service bus или имелся ввиду EJB?
Насколько сложна бизнес-логика? требуется поодержка транзакционности?

 

[Pete]

Посмотреть вложение 1054

На этом изображении представлена планируемая архитектура будущего проекта. Нужно написать "что-то", что будет принимать XML фрагменты с одной стороны, обрабатывать их и в базу что-то совать, а затем эти XML конвертировать в другие XML(другого формата) и отправлять их дальше по другим адресам. И затем ждать ответа от них, снова переделывать формат, что-то писать в БД и отсылать тому от кого изначально пришел запрос. Своеобразный прокси нужно сделать.

Все должно работать на HTTPS. Держать нагрузку 300000 тысяч в день запросов или больше...

Кто что бы предложит?!!! Я пока вижу обычный сервлет, работающий по HTTPS.

Может кто-нибудь порекомендует использовать ESB или еще что-нибудь?

Заранее благодарен

Варианты разные есть. Лучше, конечно, использовать хорошо масштабируемые технологии. Многое зависит от деталей и ограничений. Но можно преложить, например, такой вариант.
Сервлет получает данные по HTTPS, потом разбирает XML с помощью любого удобного вам парсера или средства отображения XML->Java Objects. Если скорость критична, а xml-ки не сложные SAX или StAX. Трансформация ручками, маппером или через XSLT (производительность не тестировал). Сохранение в базу можно сделать через вызов plain java code/JMS/Stateless Session Bean. Если к сохраняемым данным постоянный доступ не требуется, т.е. просто как лог событий, то можно обойтись JDBC иначе стоит подумать как организовать кэширование, чтобы не нагружать базу.
Смею предположить, что в базу можно писать асинхронно (sic! JMS), если так, то это хорошо, т.к. при большом количестве запросов, коннектов к базе всем может не хватить, имхо лучше ставить в очередь чем создавать новое соединение. В любом случае стоит озаботиться пулом коннектов к базе. Ну и HttpClient еще прикрутить для передачи сформированных xml-ек на другие адреса.

 

[alexlexa]

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

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

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

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

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


Спасибо

 

[Pete]

Не совсем мне понятны ваши требования... что значит "только https", "только XML"? И вообще странно рисовать архитектуру, не зная точных требований к системе. Если читать не собираетесь, хибернейт вам точно не нужен, если лень возиться с маппингом, можно обойтись Spring JBDC.

 

[Kmet]

EJB здесь может понадобится для горизонтального маштабирования, но его применение целесообразно только в случае достаточно сложной бизнеслогики. Причин для использования ESB я не вижу, все же это инструментарий для интеграции. На счет кеширования я бы лишний раз подумал. Если запись в базу превалирует над чтением, то кэш может стать лишней обузой. У меня сложилось впечатление, что работа с БД не должна устать узким горлышком, в таком случае действительно целесообразно использование ORM технологий для ускорении разработки. Другое дело работа с XML. В особенности создание и изменение, даже если делать ручками, получится достаточно требовательно к процесорному времени и, в особенности, к памяти. Так что о поддержке работы на кластере стоит подумать уже сейчас.

 

[alexlexa]

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

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

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

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

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

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

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

P/S/ Над кешированием, подумаю, все равно пригодится, так как маршрутизацию (куда перенаправлять запрос) все равно придется читать из базы.

 

[Kmet]

<!--QuoteBegin-alexlexa+27:09:2007, 11:40 -->
<span class="vbquote">(alexlexa @ 27:09:2007, 11:40 )</span><!--QuoteEBegin-->1) Как лучше использовать сервлеты -
- один сервлет на все запросу(это по умолчанию так сервлеты работают)
- один запрос на один сервлет (это делается через реализацию SingleThreadModel).

[snapback]79764" rel="nofollow" target="_blank[/snapback]​

[/quote]

SingleThreadModel is depricated.
Если быть точным, спецификация устнавливает, что один экземпляр сервлета может разделятся между несколькими запросами, количество экземпляров не оговаривается.

<!--QuoteBegin-alexlexa+27:09:2007, 11:40 -->
<span class="vbquote">(alexlexa @ 27:09:2007, 11:40 )</span><!--QuoteEBegin-->2) А вообще сервлеты можно распределить через кластер, есть у кого-нибудь опыт? Ведь моим сервлетам друг с другом общаться не нужно будет, и общее место у них - только база данных.

[snapback]79764" rel="nofollow" target="_blank[/snapback]​

[/quote]

Tomcat поддерживает кластерицию. Но в твоем случае это не принципиально, задача легко маштабируема и ручками.

<!--QuoteBegin-alexlexa+27:09:2007, 11:40 -->
<span class="vbquote">(alexlexa @ 27:09:2007, 11:40 )</span><!--QuoteEBegin-->на Tomcat же не серьезно для такого проекта

[snapback]79764" rel="nofollow" target="_blank[/snapback]​

[/quote]
ну я бы так не сказал, со своими задачами он справляется не плохо.

 

[alexlexa]

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

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

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

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

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

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

 

[ekr]

<!--QuoteBegin-alexlexa+30:09:2007, 02:05 -->
<span class="vbquote">(alexlexa @ 30:09:2007, 02:05 )</span><!--QuoteEBegin-->1) Какой лучше библиотекой пользоваться для маппинга XML на Java Objects и обратно?

[snapback]80109" rel="nofollow" target="_blank[/snapback]​

[/quote]
Mapping xml на java-объекты - JAXB (Binding) или Apache XMLBeans

<!--QuoteBegin-alexlexa+30:09:2007, 02:05 -->
<span class="vbquote">(alexlexa @ 30:09:2007, 02:05 )</span><!--QuoteEBegin-->2) Чем воспользоваться для распределенного кеширования объектов из базы, которые я получу через Spring JDBC (они ведь не будут закешированны).

[snapback]80109" rel="nofollow" target="_blank[/snapback]​

[/quote]
Или самопальное решение с использованием мягких ссылок, или взять готовое кешируещее решение. Кстати, с Oracle AS такое поставляется/ Имеет смысл задуматься, если в проекте используется OAS. Или open source солюшн взять.