Доброго времени суток, господа.

На данный момент есть следующая архитектура.

1. Толстый клиент написанный на mod_perl + templates + Apache::DBI + etc... под Apache 1.3 под *nix.
2. Oracle 8i for Linux, в нем реализована бизнес-логика и большинство бизнес приложений работы предприятия, в виде PL/SQL процедур.

Хотим перевести всю систему на 3-х звенную:
1. Тонкий клиент под апач
2. Application server реализующий бизнес логику вместо использования PL/SQL
3. Oracle 8i уже не как application server а просто как базу данных.

Предпологаемые приемущества:
1. Разгрузка базы работающей как OLTP.
2. Возможность использовать CMS менеджментом компании, т.е. разделение кода и дизайна.
3. Веcь функционал собирается в одном месте, на Application server, допустим Oracle Application Server, и при его большой нагрузке, есть возможность сделать кластер из них.

------------------

Интересуют в общем-то вопросы следующего характера:
1. Какой Application Server использовать?
2. На каком языке писать? Какй язык _более_ функционален для работы в Application enviroment? Java, Delphi, C++, etc...
Может все так и писать на PL/SQL? Но, тогда Application Server должен его понимать (Oracle вариант) + уметь компилировать и предоставлять достаточную скорость.
В общем более интересует функционал, наличие библиотек, etc...
3. Встреченные проблемы и подводные камни.

Буду рад ответить на _конкретные_ вопросы, и буду рад любым вашим предложениям.


С уважением,
lightspeed

2Yo!:
Железо - разное.
Я понимаю, что 3-х звенка довольно широкое и всеобъемлющее понятие. Но, все-же хотелось бы развести все задачи строго по функционалу.
1. Oracle - Не загружать его дополнительной функциональностью. Тем более для OLTP режима. У него и так задач хватает, например sync/async replication.
2. Application server - набор библиотек и приложений основанных на этих библиотеках, реализующих заданную функциональность.
3. Web server/Mail server/SMS/some other services - обращаются к application server'u за заданной функциональностью.

Вот. Соответственно, что бы обеспечить приемлемую производительность докупается необходимое железо. Все равно, его total TCO намного меньше стоимости затрат во время остановки сервисов или стоимости софта.

---
Best regards,
lightspeed

2Alexey Rovdo:
На данный момент все так и работает.
Вот структура:
1. Primary Oracle8i server - OLTP handlers
2. Secondary Oracle8i server - user applications, synchronously replicated to primary.
3. Third backup server - tape/dvd BACKUP server, asynchronously replicated to secondary database server.

Соответственно, все затраты по обработке пользовательских приложений лежат на secondary database server, который синхронно реплицирован с primary. Репликация сидит на отдельном 1gbit/sec интерфейсе, кроме нее ничего там не работает. Отдельный Gbit switch, внутренняя шина 160Gb/sec.

Но, дело не в этом. Просто, как я понимаю application server может хранить и запускать процедуры высокого уровня, разработанные на нескольких языках. И делать это централизованно. А, при нехватке мощности скажем, можно просто добавить такую-же машинку с application server и все.

Сейчас же у нас разнородная система: pl/sql packages, mod_perl handlers, OCI applications, c billing modules, etc...

Т.е. возвращаемся к моему 1-му вопросу...