bob_jМне почему-то не очень нравится идея запускать процесс на сервере с помощью веб-приложения.

На линухе же довольно легковесные процессы. Для винды, конечно же, повод задуматься. А что PHP с файлами не умеет работать?

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

bob_jВ идеале, по-моему, веб-клиент вообще не должен знать о существовании средств, которыми сервер вернет запрошенные файлы.

А на PHP разве знает?

bob_jВозможно должно генерироваться какое-то событие, например, завершение формирования списка. Слушать это событие должно приложение, или класс которое и будет работать с файлами.
Направление верно, чего нельзя сказать о выводах ниже.

bob_jБыла мысль сделать некий семафор, наличие которого было бы указанием на начало обработки файлов. Появление этого семафора проверять по cron например каждые 10-20 секунд. Но это значит увеличение нагрузки на сервер независимо от того, запрашивал ли клиент файлы, или нет. Я правильно рассуждаю, не так ли?
Да. Вот только почему вы отбросили "события". Стоит знать что обработка "событий", обычно, организована в виде очередей. А не таймеров с семафорами. Pure JEE аналог это JMS. С другой стороны вполне можно ограничиться асинхронными сервлетами в Servlet 3.0. Хотя API у них немного стремное. Что, впрочем, вполне обычно для JEE.

bob_j В тоже время одновременно может прийти несколько запросов на разные файлы от разных посетителей и здесь, как мне кажется, уже всплывает вопрос многопоточности и параллельности.
Ну, вообще-то любое web приложение уже подразумевает многопоточность и праллельность.

bob_jПодскажите пожалуйста, где можно почитать о подобных решениях, посмотреть примеры?
Я бы Фаулера читал. Enterprise Patterns - сборник типовых решений. Потому как именно недостаток знания различных типовых решений порождает каких-то монстров в виде cron-семафоров.

Можно сделать так
id файлов храним в HttpSession клиента
после оформления покупки запускаем из сервлета асинхронный "процесс" упаковки файлов
http://docs.oracle.com/javaee/7/tutorial/doc/servlets012.htm
по завершении отдаём файл клиенту

Я недавно делал парсер файлов. jQuery UI Progressbar + jquery-stream + Servlet 3.0 вполне нормально позволили запилить COMET и мониторить процесс обработки файла на клиенте. Единственной неожиданностью стала небольшая проблема с GZIP.

bob_jПисать серверное приложение на РНР для связи веб-приложения и 1С?
Любой interop сейчас через XML SOAP Web Service реализуется. При этом я более чем уверен что в PHP вас ожидает меньше сюрпризов при использовании web сервисов. А в Java вы легко столкнетесь с тем что дефолтная реализация JAX-WS окажется чем-то не совместима с 1С и нужно будет изучать и сторонние реализации вроде CXF. С настороженностью теперь смотрю на перспективы использовать JAXB и JAX-WS. Столько крови попили уже.

bob_jМне показалось, что в данной ситуации связка Servelt+EJB самое то. Я вроде где-то читал, что Spring предлагает какую-то облегченную замену EJB.
EJB сам по себе сложно устроен. Надо его понимать чтобы применять правильно и к месту.
EJB API раньше был нереально перегружен. Но сейчас его сильно упрастили за счет IoC и аннотаций.
Spring более прямолинейный, чем EJB. Но за годы развития он на столько оброс всякой фигней, что тоже надо понимать как всё устроено, прежде чем использовать. Ну, и действительно ли нужны EJB сказать сложно. Нужно знать и понимать требования к проекту.
Отказоустойчивость? Масштабирование?

bob_jЯ имел в виду, что приложение, подготавливающее заказанный архив и делающее всякие другие операции на сервере, должно быть многопоточным.
ОК. Это всегда принимается по-умолчанию для любого серверного приложения. Поэтому утверждать очевидное не стоит.

bob_jпросто давно хотел разобраться в Java EE и этот случай показался мне весьма подходящим.
Ну, вот с этого надо было начинать. Если есть желание изучить JEE, то берем и применяем полный стэк JEE: JMS, Session Beans, JPA, CDI.

bob_jЕсли все же отказаться от Java EE, то как правильно сделать связь между веб-приложением, реализованном на РНР, и серверной частью, которая может быть реализована на чем угодно? У меня большой пробел в знаниях именно об этом моменте. Как организовывается взаимодействие? До этого писал простые сайты на Друпале и с помощью разных фреймворков, но там все решалось внутри самой CMS, или на уровне модели которая работала с БД, но не привлекала ни каких других сторонних ресурсов.
Концептуально разницы никакой нет на чем это писать.
Пришел клиент его состояние живет в сессии - реализация есть везде
Захотел клиент забрать файлы - создали событие, положили в очередь - реализация есть везде
Обработчик событий в очереди параллельными потоками разгребает события, пакует файлы, дергает 1С. В общем, запускат бизнес-процесс. - релизация есть везде.

bob_jЯ что-то туплю в последнее время, сказалась бессонная ночь :( , не соображу как поисковый запрос гуглу сформулировать. Очередь обработки событий, так? Вы это имели в виду? Подскажите пожалуйста, где можно глянуть?
Java, PHP или теория? Google -> Message Queue, Event Queue, Asynchronous processing

bob_jМне нужно разобраться с созданием и обработкой событий. Подскажите, где можно найти документация, примеры, спецификация и т.д. по данной теме?
https://www.google.com/search?q=PHP async tasks
https://www.google.com/search?q=PHP async jobs
https://www.google.com/search?q=PHP message queue
https://www.google.com/search?q=Java async tasks
https://www.google.com/search?q=Java async jobs
https://www.google.com/search?q=Java message queue

bob_jСпасибо большое. Буду разбираться.
Хочу сраз рассказать один момент. Возможно его сразу так не ведзе разъясняют.
Концепции Async Job от Message Queue - в плане реализации внутри слабо чем отличаются. Но есть важное различие в том как они используются.
Async Job - подразумевает что нужно выполнить фоновую задачу. И вам всё равно как именно это произойдёт. Т.е. вы указываете "системе" запустить некий код асинхронно. А "система" за вас создаёт поток, помещает код в очередь и вам лишь предоставляет API для того чтобы узнать результат асинхронного выполнения.

Message Queue отличатеся тем, что у вас на руках ещё и контроль над тем очередью. Вы заботитесь о том чтобы туда поместить событие и потом его вычитать. У вас больше контроля над состоянием очереди. И, зачастую, у вас есть способы её, например, персистить.

То есть принцип работы один и тот же. Просто в материалах будет разное описание и разные API. Async - более простой для изучения и использованя. Message Queue - больше даст понимания что как устроено и что с этим можно делать и какие вообще бывают сценарии.