Можно ли вернуть объекты из WebService?

Как уже упоминалось, вы можете сделать это в .net через сериализацию. По умолчанию все собственные типы являются сериализуемыми, так что это происходит автоматически.

Однако если у вас сложные типы, вам нужно пометить объект атрибутом [Serializable]. То же самое касается сложных типов в качестве свойств.

Так, например, вам нужно иметь:

[Serializable]
public class MyClass
{
    public string MyString {get; set;}

    [Serializable]
    public MyOtherClass MyOtherClassProperty {get; set;}
}

Да: в .NET они называют эту сериализацию, где объекты сериализуются в XML и затем восстанавливаются потребляющим сервисом обратно в исходный тип объекта или суррогат с той же структурой данных.

Если объект может быть сериализован в XML и может быть описан в WSDL, тогда да, можно вернуть объекты из веб-службы.

.NET автоматически делает это с объектами, которые сериализуемы. Я уверен, что Java работает так же.

Вот статья, в которой говорится о сериализации объектов в .NET: http://www.codeguru.com/Csharp/Csharp/cs_syntax/serialization/article.php/c7201

Там, где это возможно, я перемещаю объекты в XML - это означает, что веб-служба является более переносимой - тогда я могу получить доступ к службе на любом языке, мне просто нужно создать преобразователь синтаксического анализатора / объекта на этом языке.

Поскольку у нас есть WSDL-файлы, описывающие сервис, в некоторых системах это практически автоматизировано.

(Например, у нас есть сервер, написанный на чистом Python, который заменяет сервер, написанный на C, клиент, написанный на C ++ / gSOAP, и клиент, написанный на Cocoa / Objective-C. Мы используем soapUI в качестве среды тестирования, которая является написано на Java).

Можно возвращать объекты из веб-службы, используя XML. Но веб-сервисы должны быть независимыми от платформы и операционной системы. Сериализация объекта просто позволяет вам сохранять и извлекать объект из потока байтов, такого как файл. Например, вы можете сериализовать объект Java, преобразовать этот двоичный поток (возможно, с помощью кодировки Base 64 в поле CDATA) и передать его клиенту службы.

Но клиент сможет восстановить этот объект, только если он будет основан на Java. Более того, для сериализации объекта и его точного восстановления требуется глубокая копия. Глубокие копии могут быть дорогими.

Лучший способ - создать схему XML, которая представляет документ, и создать экземпляр этой схемы со спецификой объекта.

@Brian: я не знаю, как все работает в Java, но в .net объекты сериализуются вплоть до XML, а не строк base64. Веб-сервис публикует файл wsdl, содержащий определения методов и объектов, необходимые для вашего веб-сервиса.

Я надеюсь, что никто не создает веб-сервисы, которые просто создают строку base64

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

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

Я должен не согласиться с этим, так как это довольно узкий комментарий. Использование веб-службы, которая может сериализовать доменные объекты в XML, означает, что это облегчает работу клиентов с теми же объектами домена, но также означает, что эти клиенты ограничены использованием определенного веб-сервиса, который вы представили, и он также работает в наоборот, позволяя другим клиентам не знать об объектах вашего домена, но по-прежнему взаимодействовать с вашим сервисом через XML.

Даниэль Ожер:
Как уже говорили другие, это возможно. Однако, если и служба, и клиент используют объект, имеющий одинаковое поведение домена с обеих сторон, вам, вероятно, сначала не понадобился сервис.

lomax: Я должен не согласиться с этим, так как это довольно узкий комментарий. Использование веб-службы, которая может сериализовать доменные объекты в XML, означает, что это облегчает работу клиентов с теми же объектами домена, но также означает, что эти клиенты ограничены использованием определенного веб-сервиса, который вы представили, и он также работает в наоборот, позволяя другим клиентам не знать об объектах вашего домена, но по-прежнему взаимодействовать с вашим сервисом через XML.

@ Lomax: Вы описали два сценария. Сценарий 1: клиент перетаскивает сообщение XML обратно в тот же объект домена. Я считаю, что это «возвращение объекта». По моему опыту это плохой выбор, и я объясню это ниже. Сценарий 2: клиент перекомпилирует сообщение xml в нечто иное, чем тот же объект домена: я на 100% отстаю от этого, однако я не считаю, что это возвращает объект домена. Это действительно отправка сообщения или DTO.

Теперь позвольте мне объяснить, почему истинная / чистая / не DTO-сериализация объектов через веб-сервис обычно плохая идея. Утверждение: для того, чтобы сделать это в первую очередь, вы должны либо быть владельцем клиента и службы, либо предоставить клиенту библиотеку для использования, чтобы они могли повторно преобразовать объект в его истинный тип. Проблема: этот объект домена как тип теперь существует и принадлежит двум полуотносимым доменам. Со временем, возможно, потребуется добавить поведение в одной области, которое не имеет смысла в другой области, и это приведет к загрязнению и потенциально болезненным проблемам.

Я обычно использую сценарий по умолчанию 2. Я использую сценарий 1 только тогда, когда для этого есть непреодолимая причина.

Я прошу прощения за столь краткий с моим первоначальным ответом. Я надеюсь, что это проясняет ситуацию до такой степени, насколько мое мнение. Lomax, казалось бы, мы наполовину согласны;).

JSON - это довольно стандартный способ передачи объектов по сети (как часть javascript). Во многих языках есть библиотека, которая преобразует код JSON в нативный объект - см., Например, simplejson в Python.

Дополнительные библиотеки для использования в формате JSON см. На веб-странице JSON.