funikovyuriА чем не устраивают сервлеты? Они подходят под ваши требования, кроме них подойдут пожалуй только WebServices и Corba

Я использую сервлет-контейнер, HTTP GET/POST запросы с параметрами, ответы сервера в XML формате. На стороне сервера для формирования ответов используются XMLBeans (ну и, рзумеется. база данных). Клиенты есть на Java, MS VC++, VB, .NET. Все клиенты (каждый по-своему) умеют посылать HTTP GET/POST и парсить XML сервера.

В итоге получается XML RPC. Я собирался использовать SOAP (который успешно использовал раньше), но обнаружил, что это будет громоздко и совершенно не нужно.

Если хотите, гляньте в описания моих недавно сделанных API по этой схеме. Эти API открытые и используются разработчиками клиентских приложений к моим серверам:

ftp://cascade.virtual.vps-host.net/ObjectPublisher_API_Developers_Kit/OnDemandPublishing_API/API_Guide_ver0.doc

ftp://cascade.virtual.vps-host.net/ObjectPublisher_API_Developers_Kit/SecurityManagement_API/API_Guide_ver0.doc

ftp://cascade.virtual.vps-host.net/ObjectPublisher_API_Developers_Kit/VariableContentPackagePublishing_API/PkgPubControl_Guide_ver0.doc

Там же есть XML Schemas для каждого API.

М.Голованов[quot funikovyuri]Если хотите, гляньте в описания моих недавно сделанных API по этой схеме. Эти API открытые и используются разработчиками клиентских приложений к моим серверам:


Пардон, последняя ссылка указывает на описание примера клиентского приложения (Windows COM). Правильно будет

ftp://cascade.virtual.vps-host.net/ObjectPublisher_API_Developers_Kit/VariableContentPackagePublishing_API/API_Guide_ver0.doc

ежемухаНо, насколько я понял, все-таки приходится придумывать свой API?

ежемухаНо, насколько я понял, все-таки приходится придумывать свой API?

Что значит придумывать - определять свои вызовы и их параметры, а таже структуру ответов сервера? ... естественно. Мои API - это только для моих серверов.

котысоздание и публикация в контейнере простого сервиса (классический "калькулятор") с использованием средств IDE - 5 минут, подключение внешнего сервиса - 1 минута. о возможности прозрачного для клиента переезда на ejb я даже не говорю.

вообще я считаю игнорирование современных стандартов смертным грехом архитектора системы.

Автору этой реплики: поздравляю. Нос вы мне не утерли, но кнопки нажимать научились.

Всем заинтересованным:

я этот подход, сказать честно, придумал не сам. Я года два до этого имел счастие работать SOAP, но в конце концов обнаружил, что наиболее используемыми оказываются Веб-сервисы, построенные именно по такой схеме. Например, 99% разработчиков клиентских приложений для Amazon.com (Amazon ECS API) используют именно эту схему (у них она называется REST requests), другую (SOAP requests) не использует практически никто. То же самое для eBay API.

Поработав с Amazon (это был проект перед текущим), я окончательно понял, что SOAP для целей, для которых создаются такие API, избыточен и чреват тем, что разработка клиентских приложений упрется в неквалифицированность разработчиков и тем самым в невостребованность API. Причем последнее обстоятельство оказалось решающим. И теперь у нас все хорошо. Индусам легче соорудить простой HTTP вызов, чем прикручивать к своим приложениям SOAP клиенты, в кторых они ни уха ни рыла... а распарсить XML ответ сервера они так или иначе способны.

[quot ежемухаНадо сделать для каждой платформы библиотеку, которая умела бы вызывать этот сервлет? А клиентская часть на C# или Delphi пользовалась бы этой библиотекой (COM-объектом)?[/quot]

Вы там рядом с описаниями API и XML схемами можете найти и клиентские COM компоненты, и пример .NET клиента. Клиентская библиотека в Вашем смысле есть и для Java (но он там не выложен, поскольку им пользуется только один клиент, сподобившийся писать клиентское приложение на Swing).

Если у Вас клиенты ограничены Windows, вам, конечно, сам Бог велел написать COM компонент, который бы делал вызовы к серверу и обрабатывал XML ответы сервера. Используя MSXML.

котывы все же потрудитесь объяснить, чем соап _избыточен? интересно, правда

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

ежемухаА на Дельфи можно будет написать клиент к SOAP - серверу? То есть я понимаю, что можно все. Но я понял из фака по axis, что на java или .NET это делать легко и приятно, хотелось бы, чтобы это было также и при написании простой .dll или .so.

Однако я понимаю М.Голованова и его индусскую проблему. Но моя-то проблема в том, что я не смогу так красиво, на английском языке описать свой API, если создам его. Тем более не хотелось бы делать самому специальные клиентские библиотеки для всех платформ, с которых будет вызов моего сервера

А вот описать поля запроса и поля ответа - делов на одну страницу. С указанием "дальше см. доку по SOAP".

1. Клиент для SOAP может быть написан на чем угодно. Я лично успешно писал таковые на PHP, MS VC++ (не говоря о Java и .NET).

2. У меня (да и у вас) не "индусская" проблема. У меня опыт, который показывает, что почти любой програмист в состоянии запрограммировать HTTP запрос и разбор XML ответа, но далеко не любой в состоянии разобраться с SOAP. Это только кажется, что легко. Нужно ведь, чтобы РАБОТАЛО.

Кроме того, я не писал и не собираюсь писать клиентские библиотеки для всех платформ. В 90% случаев все легко просекают сами, а в 10% приходится разжевывать (те примеры, которые у меня есть, результат такого разжевывания).

3. Так и у меня описаны поля запроса и ответа. И все.

PS. Если у ваc все так просто, то можно вообще не морочиться с XML. Ваши вызовы могут иметь форму простого HTTP GET запроса типа


а ответы сервера - форму текстового файла с парами "наименование/значение" типа


разобрать текст по строкам, а затем отделить наименование от значения уж точно любой программист сможет.

Вот пример вызова / ответа "тарого" Web-сервиса у моего клиента:

http://my.objectpublish.com/catalogs/servlet/CatalogServlet?action=getJobAccounting&JOBID=OPS_BatchImport_63907

Результат - пары "наименование/значение", разделенные "палочкой" (|). И ничего... все довольны.

Короче, в чистом осадке мой совет получается такой.

1. Запросы - HTTP GET с указанием типа операции (имени функции) и (необязательно) списка параметров вызова (наименований и значений).

2. Сервлет разбирает запрос, его параметры и вызывает соответствующую функцию.

3. Функция формирует ответ в виде текстового файла (content-type="text/plain; charset=utf-8") или XML файла (content-type="text/xml; charset=utf-8").

4. Сервлет переправляет это файл (ответ сервера) в выходной поток (пример текстового ответа):

Pitbull terrierкстате по поводу амазона - его SOAP api не используется разработчиками только по причине наличия в нем старых багов, которые, похоже, никто не собиратся фиксить

Что первее - курица или яйцо?... не используют, потому что не фиксят, или не фиксят, потому что не используют?...

В REST проблем тоже хватает (вы посмотрите на описание API - объем и функциональность впечатляют), но это проблемы не API как такового (и его использования), а реализации (функций их серверов которые исполняют запросы), он РАБОТАЕТ и им ПОЛЬЗУЮТСЯ.

KBoristo М.Голованов

Опубликованая Вами информация оказалась очень полезной и для меня. Но у меня есть потребноить и клиентом пересылать XML файлы серверу, не подскажете как это лучше реализовать?

У меня обычно сервер принимает от клиента запросы в двух вариантах:

* HTTP GET - запрос с параметрами типа

http://www.server.net/processor.do?Operation=GetProductByLink&SessionID=7640160&ProductLinkRowID=3482&ProductRowID=10208&_=

* HTTP POST - запрос с XML документом в теле запроса. В этом случае Operation является одним из элементов документа (имя функции, которую нужно выполнить над пересылаемыми данными).

Например, если сервер получает документ


то ему (серверу) понятно, что а) ему надо выполнить функцию SaveProduct, б) данные для выполнения этой функции содержатся в элементе SaveProductRequest (обязательном в документе для запросов на SaveProduct. Дальше все просто.

Короче, если клиент хочет получить данные, он посылает HTTP GET. Если клиент хочет отправить данные, он посылает HTTP POST с XML документом в теле запроса.

Разумеется, можно было бы всегда использовать только HTTP POST (подобно тому, как это делает SOAP), то есть и первый запрос, приведенный выше, послать как XML документ вида


но поскольку клиенты обычно часто читают данные и редко отправляют, то HTTP GET экономит время (так как разборка GET запроса мног проще парсинга XML документа).