вторник, сентября 11, 2007

Это не web сервисы...

Web сервисы завоевали свое место под солнцем в инфраструктуре приложений масштаба предприятия. Теперь среди разработчиков и пользователей таких систем часто можно слышать диалоги вроде: "Нам нужны сводные данные по продажам из вашей системы. У вас нет подходящего web сервиса?". И часто подходящий сервис находится.
К сожалению, эти web сервисы зачастую сделаны так, что назвать их не то что "подходящими", но и "web сервисами" просто не поворачивается язык.
Вот пример (я использую псевдокод для описания контракта сервиса вместо WSDL, чтобы было понятнее):



[WebMethod]
public XmlNode CT(DateTime dateFrom);

или

[WebMethod]
public string GetSales(string from, string to, string office);



Делать какие либо предположения, для чего предназначен метод CT() на основе его контракта абсолютно бесперспективное занятие. То же можно сказать и о выдаваемых им результатах. "Чтобы понять - надо жевать" - чтобы разобраться с результатами надо вызвать метод и вывести полученный XML на печать или экран, а затем читать его и думать что же делать дальше.
А вот, извините за выражение, стринговый контракт метода GetSales() по заверениям его разработчиков был разработан исключительно в целях кроссплатформенной совместимости. При этом, выяснились удивительные вещи. Оказалось что передавать даты можно только в формате "DD-MM-YY", любой другой приводит к падению сервиса. Результирующая строка содержит в себе довольно кучерявый XML в неизвестной кодировке, а при отсутствии продаж за период результат содержит (внимание!) строку вида: "There are not sales {имя офиса} for period".
Примеры подобного рода можно продолжать долго. Однако все это не web сервисы.
Факт, что Web сервисы на сегодня, это самый простой, быстрый и удобный способ организовать межпрограммное взаимодействие как на .NET так и на Java. И многие используют их именно как механизм удаленного вызова через SOAP over HTTP. И забывают при этом об основном отличие web сервисов от механизмов RPC - способности к само-описанию посредством метаданных представленных в WSDL.
WSDL описывает два важнейших аспекта сервиса: способ вызова методов (binding and ports) и формат передаваемых сообщений (message and types). В приведенных в качестве примера сервисах невозможно сказать, что либо определенное о формате их сообщений. Использование такого сервиса возможно только в комплекте с программистом его написавшим, а при недоступности последнего такие сервисы становятся совершенно бесполезны.
В общем, "сказка ложь, да в ней намек,/ добрым молодцам - урок". Урок прост:
- не используйте в сообщениях web сервисов XML не описанный в WSDL схеме сервиса;
- не используйте в сообщениях web сервисов строки вместо элементарных типов
- не используйте в сообщениях web сервисов строки для передачи произвольного XML;
- не используйте в web сервисах нетипизированные DataSet-ы;
- комментируйте контракты web сервисов, это как раз тот случай, когда комментариев много не бывает.

3 комментария:

Анонимный комментирует...

Имхо стоит указать, что по хорошему, для передачи даных должны применяться специальные DTO (data transfer objects) которые идеологичеси не должны быть бизнес объектами и DB обьектами.

Sergey Rozovik комментирует...

Для тех кто интересуется данной темой есть более подробная статья Проектирование web сервисов . А также еще несколько статей в моем блоге под тэгом Web Services.

Анонимный комментирует...

Вот, для WCF:
http://idesign.net/idesign/download/IDesign%20WCF%20Coding%20Standard.zip