Спасибо за ответ! В принципе ответы на свои вопросы получил. Разве что в деталях пока еще есть небольшие вопросы.
K>>Можно для каждого приложения сделать свой web service. Если делать так, то как в SOAP Responce message будет описываться возвращаемый файл? Как указывать в WSDL, что возвращается файл? M>Что значит возвращается файл?
То что результаты выполнения приложения помещаются в файл. Вы так это и поняли, судя по ответу
M>Можно вернуть например полное имя файла, web-service генерит файл и возвращает URL
Согласен. Наверное глупый вопрос: а как это реализовать? Т.е. например я завожу директорию где после каждого запроса к веб-сервису появляется файл. Мое сомнение здесь во времени жизни такого файла. Т.е. я не хочу устраивать файловую помойку — скажем час пускай этот файл лежит, но не больше. Понятно, можно завести скриптик который будет вычищать директорию каждый час. Или как еще это можно сделать?
M>этого файла, а можно вернуть содержимое этого файла, например в base64.
Наверное вот это пока мне подойдет больше всего.
>SOAP/WSDL request'е что у веб-сервиса только один входной параметр в >виде XML-файла? Какие недостатки могут быть у такого способа доступа к приложениям (в котором во входном файле до>лжно быть описано вызываемое(ые) приложение(ия), файл парсится, извлекаются какие приложения нужно выполнить и вх>одные данные для них, и затем происходит вызов приложений)? M>Тоже самое — ложить файлики куда-нибудь и передавать их имена, как обычные строки, M>или передавать их содержимое в base64. С возвращаемыми значениями тоже самое.
ОК
M>Я бы сказал, что 2-ой подход немного более универсальный, M>но зато 1-ый позволит настроить индивидуальные wsdl-ки для каждого приложения. M>В wsdl-ку можно засунуть схему и содержимое реквеста и респонса будет валидироваться и парсится согласно схеме в wsdl, особенно если весь код будет сгенерирован автоматически, но это накладывает определенные ограничения. M>Я так понял, что приложения уже готовы, тогда 2-ым способом будет намного проще все реализовать.
Спасибо за комментирий! А почему вы считаете 2-ой подход более универсальным? Т.е. я имею ввиду следующее:
в первом подходе, когда для каждого приложения есть свой WSDL — мне кажется доступ к приложениям более унифицирован потому, что consumer для доступа требуется только знание WSDL (который широко распространен);
во втором же подходе, WSDL знать не нужно, но для вызова приложений нужно понять формат входного XML-файла (а это формат фактически никому не известен).
p.s. В моем конкретном случае формат входного и выходного файлов будет задаваться в уже имеющемся распространенном XML-формате.