Есть следующие вопросы, один общего характера:

На данный момент имеются несколько приложений (12 штук если быть точным), работающих след.образом: вход — строка/строки, на выходе XML, определенного формата (во всех приложений используются только две XML-схемы). Выход нескольких приложений может быть объединен в один файл. Сейчас нужно сделать программный доступ к этим приложениям.

Можно для каждого приложения сделать свой web service. Если делать так, то как в SOAP Responce message будет описываться возвращаемый файл? Как указывать в WSDL, что возвращается файл?

Другой подход — сделать один веб-сервис, который на входе получает XML-файл и возвращает тоже XML файл. Во входном XML-файле будут задаваться какое(ие) приложение запустить и с какими входными данными. Как описывать в SOAP/WSDL request'е что у веб-сервиса только один входной параметр в виде XML-файла? Какие недостатки могут быть у такого способа доступа к приложениям (в котором во входном файле должно быть описано вызываемое(ые) приложение(ия), файл парсится, извлекаются какие приложения нужно выполнить и входные данные для них, и затем происходит вызов приложений)?

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

K>Есть следующие вопросы, один общего характера:

K>На данный момент имеются несколько приложений (12 штук если быть точным), работающих след.образом: вход — строка/строки, на выходе XML, определенного формата (во всех приложений используются только две XML-схемы). Выход нескольких приложений может быть объединен в один файл. Сейчас нужно сделать программный доступ к этим приложениям.

K>Можно для каждого приложения сделать свой web service. Если делать так, то как в SOAP Responce message будет описываться возвращаемый файл? Как указывать в WSDL, что возвращается файл?

Что значит возвращается файл?
Можно вернуть например полное имя файла, web-service генерит файл и возвращает URL
этого файла, а можно вернуть содержимое этого файла, например в base64.


K>Другой подход — сделать один веб-сервис, который на входе получает XML-файл и возвращает тоже XML файл. Во входном XML-файле будут задаваться какое(ие) приложение запустить и с какими входными данными. Как описывать в SOAP/WSDL request'е что у веб-сервиса только один входной параметр в виде XML-файла? Какие недостатки могут быть у такого способа доступа к приложениям (в котором во входном файле должно быть описано вызываемое(ые) приложение(ия), файл парсится, извлекаются какие приложения нужно выполнить и входные данные для них, и затем происходит вызов приложений)?

Тоже самое — ложить файлики куда-нибудь и передавать их имена, как обычные строки,
или передавать их содержимое в base64. С возвращаемыми значениями тоже самое.

Я бы сказал, что 2-ой подход немного более универсальный,
но зато 1-ый позволит настроить индивидуальные wsdl-ки для каждого приложения.
В wsdl-ку можно засунуть схему и содержимое реквеста и респонса будет валидироваться и парсится согласно схеме в wsdl, особенно если весь код будет сгенерирован автоматически, но это накладывает определенные ограничения.

Я так понял, что приложения уже готовы, тогда 2-ым способом будет намного проще все реализовать.

Спасибо за ответ! В принципе ответы на свои вопросы получил. Разве что в деталях пока еще есть небольшие вопросы.

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-формате.

Здравствуйте, 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 можно нагенерировать и код для дополнительной валидации реквеста,
и т.д. и т.п.