Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
На основании изложенного выше материала иерархическая структура работ примет следующий вид:И дальше идет список из 6 пунктов без какой-бы то ни было иерархии…
А чем разработка корпоративных веб приложений отличается от просто разработки веб приложений?
Вы спрашиваете автора или вообще?)
Обычно, в корпоративных веб-приложениях нужна интеграция с другими корпоративными веб-приложениями. Как минимум, это получения информации о пользователях из LDAP и использование SSO.
Меньше проблем с зоопарком браузеров — как правило, можно писать систему под один конкретный. С другой стороны, этот один конкретный может быть уже задан другими системами — и им может оказаться IE6.
Обычно, в корпоративных веб-приложениях нужна интеграция с другими корпоративными веб-приложениями. Как минимум, это получения информации о пользователях из LDAP и использование SSO.
Меньше проблем с зоопарком браузеров — как правило, можно писать систему под один конкретный. С другой стороны, этот один конкретный может быть уже задан другими системами — и им может оказаться IE6.
Я раньше писал корпоративные веб приложения под ie 6 с интеграцией с SAP и другими самописными корпоративными приложениями, часть из которых была написана ещё на COBOL! Чтобы добавить боли, скажу, что был проект на ExtJs (что само по себе мрачно) — представляете как оно «быстро» работало на ie 6? Нет, не представляете… пользователи сидели на тонких клиентах с подключением к терминальному серверу на Windows 2003. Минутка боли закончилась, пойду лучше почитаю нетрадиционные обзоры React и Angular!
А куда вы сервер приложений потеряли?
Браузер -> Web сервер -> Сервер приложения -> База данных
Браузер -> Web сервер -> Сервер приложения -> База данных
Сервер приложений работает либо внутри веб-сервера, либо притворяется веб-сервером — и не является чем-то принципиально отдельным.
Или я сейчас думаю про какой-то другой сервер приложений?
Или я сейчас думаю про какой-то другой сервер приложений?
Либо у вас не очень много опыта в проектировании и разработке корпоративных web приложений.
В корпоративных приложениях. Web-сервер отвечает за предоставление данных пользователю в конечном виде. Сервер приложения отвечает за бизнес-логику. Строго говоря сервер приложения может работать и без WEB сервера, планируя задания и отвечая за интеграцию со сторонними системами.
Даже на примере XAMPP должно быть очевидно, какую роль выполняет Apache, а какую PHP.
В корпоративных приложениях. Web-сервер отвечает за предоставление данных пользователю в конечном виде. Сервер приложения отвечает за бизнес-логику. Строго говоря сервер приложения может работать и без WEB сервера, планируя задания и отвечая за интеграцию со сторонними системами.
Даже на примере XAMPP должно быть очевидно, какую роль выполняет Apache, а какую PHP.
Даже на примере XAMPP должно быть очевидно, какую роль выполняет Apache, а какую PHP.Простите, что?!PHP — это язык, а не сервер приложений!
Простите, а сервер приложений вы пишете на чем? Не на языке?
На языке. Но сам язык от этого сервером приложений не становится.
Для вас поясню. В связке Apache+PHP — Apache выполняет роль Web сервера, а код, написанный на PHP роль сервера приложений (бизнес логики). На PHP можно написать скрипты, которые будут работать и без Apache.
Я привет пример с XAMPP, так как это наиболее простой и доступный пример для построения клиент-серверной архитектуры (free или low cost). Я много лет работаю с приложениями от SAP и встречал более сложные схемы.
web client -> load balancer -> n x web server -> load balancer -> n x app server -> DB cluster
Поэтому достаточно четко понимаю разницу между web server и app server — физически это могут быть не только разные приложения, но и разные машины.
Я привет пример с XAMPP, так как это наиболее простой и доступный пример для построения клиент-серверной архитектуры (free или low cost). Я много лет работаю с приложениями от SAP и встречал более сложные схемы.
web client -> load balancer -> n x web server -> load balancer -> n x app server -> DB cluster
Поэтому достаточно четко понимаю разницу между web server и app server — физически это могут быть не только разные приложения, но и разные машины.
Я понял, что вы хотели сказать. Но язык от этого сервером приложений все-таки не становится.
Да, я понял, какое место обычно отводится серверу приложений. Но, так получилось, что в наших проектах бизнес-логика находится не на отдельном сервере, а в отдельной библиотеке, поэтому до меня и не сразу дошло, что вообще имелось в виду.
Да, я понял, какое место обычно отводится серверу приложений. Но, так получилось, что в наших проектах бизнес-логика находится не на отдельном сервере, а в отдельной библиотеке, поэтому до меня и не сразу дошло, что вообще имелось в виду.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проектирование и разработка корпоративных web приложений