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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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