Здравствуйте, kudesnik, Вы писали:


M>>Можно вернуть например полное имя файла, web-service генерит файл и возвращает URL
K>Согласен. Наверное глупый вопрос: а как это реализовать? Т.е. например я завожу директорию где после каждого запроса к веб-сервису появляется файл. Мое сомнение здесь во времени жизни такого файла. Т.е. я не хочу устраивать файловую помойку — скажем час пускай этот файл лежит, но не больше. Понятно, можно завести скриптик который будет вычищать директорию каждый час. Или как еще это можно сделать?

Ну вариантов реализации тут очень много. Например файлы могут удалятся при самим веб-сервисом при последующих запросах, например: по пришествию запроса будут удалятся все файлы удовлетворяющие некоему критерию, в частности критерием может быть время создания файла. Можно использовать и другие критерии, например включать в имя файла ip-адрес из реквеста и когда пришел реквест с того же ip-адреса смело удалять предыдущий файл. Короче говоря приплести туда можно все что угодно, я надеюсь идея понятна.

M>>Я бы сказал, что 2-ой подход немного более универсальный,
M>>но зато 1-ый позволит настроить индивидуальные wsdl-ки для каждого приложения.
M>>В wsdl-ку можно засунуть схему и содержимое реквеста и респонса будет валидироваться и парсится согласно схеме в wsdl, особенно если весь код будет сгенерирован автоматически, но это накладывает определенные ограничения.
M>>Я так понял, что приложения уже готовы, тогда 2-ым способом будет намного проще все реализовать.
K>Спасибо за комментирий! А почему вы считаете 2-ой подход более универсальным? Т.е. я имею ввиду следующее:
K>в первом подходе, когда для каждого приложения есть свой WSDL — мне кажется доступ к приложениям более унифицирован потому, что consumer для доступа требуется только знание WSDL (который широко распространен);
Да, это конечно плюс, но в случае расширения системы придется приложить больше усилий, чем при использовании второго подхода.
K>во втором же подходе, WSDL знать не нужно, но для вызова приложений нужно понять формат входного XML-файла (а это формат фактически никому не известен).
Клиенту в любом случае нужно знать формат реквеста. WSDL — это более формальный способ, но зачастую присутствуют множество "джентельментских" ограничений,
которые бывает невозможно описать формально в WSDL.
Под универсальностью я имел в виду то, что этот способ позволяет легко добавить новую функциональность, использовать любые форматы файлов, а не только XML.
Например скажут потом, а хотим меньше трафик, http комрессия это конечно хорошо,
но мало, хотим передавать 7z-ипнутые или заRAR-енные файлики.
Вот после такого и приходит озарение: реквест и респонс превращаются в Base64
безповоротно. Что же касается валидации реквеста и респонса по схеме, то ее не так и трудно добавить и в клиент и в сервер.
Я на себе уже ощутил что WSDL это конечно хорошо, но далеко не всегда удобно,
в итоге у меня в проекте лежат маленькие XML файлики описывающие структуры данных,
формат реквеста и респонса для каждой операции, и по этим файликам генерируется WSDL-ка. Из файликов объемом 30K посредством XSLT рождается wsdl-ка примерно на 130K.
Такое озарение ко мне пришло тогда, когда я понял, что смотреть и редактировать эту WSDL-ну для меня очень неудобно, гораздо проще и удобнее редактировать нескольких маленьких файлов. К тому же по этим же файликам, с помощью того же самого XSLT можно нагенерировать и код для дополнительной валидации реквеста,
и т.д. и т.п.