re: Webservice returns

Fri, 21 Sep 2007 16:20:51 Z

Hi People,

I am now returning to web services and have pretty much forgotten how stuff works.

I have a web service that returns a custom type. I need the webmethod to accept a parameter of the *assembly* type as opposed to the WSDL/Webservice interpretation of the type.

Does this make sense?

I am expecting to share the assembly of classes between the web service and the client. This way I can use the same classes. Only I am not sure how I am supposed to achieve this when the WSDL is generated automatically and generated using web service versions of my classes.

Thanks in advance for any help

koder

re: Webservice returns

Fri, 21 Sep 2007 16:47:10 Z

SOA is data-oriented, not object-oriented. XML Web Services don't transfer objects, they transfer data. What the wizards do for you is to create object-oriented types based on the WSDL schema so you can more easily process the response from a Web Service. The type generated from the WSDL is not the same type as that used on the server.

The Visual Studio wizards don't support it, but the WSDL.EXE tool allows you to customize the generation of the code from the WSDL schema information, so you could get it to re-use existing types. See also http://msdn2.microsoft.com/en-us/library/system.xml.serialization.advanced.schemaimporterextension.aspx

re: Webservice returns

Fri, 21 Sep 2007 22:11:06 Z

Personally, I recommend against any attempts to share types between the client and the server. This can lead to code being designed in the erroneous belief that the client and server instances are the same object. I prefer to design as though the client and server were written in different languages and running on different platforms.

That way, when someone above my pay grade decides that we have to support a different platform, we will be able to do so.

re: Webservice returns

Fri, 21 Sep 2007 23:49:25 Z

Thanks to both of you. I understand what both of you are saying but while I agree in principle to building the web service language agnostic, i know that the "someones above my pay grade" would rather use the classes on both sides as they believe they will remain on the windows platform/c#/blah blah.

But - i will try to return an xml fragment or something instead and see how it flies. Should I return the xml of the object as a string or xmldocument or is there a type I am missing?

koder

re: Webservice returns

Fri, 21 Sep 2007 23:55:07 Z

After reading this reply, I'm no longer clear on what you're trying to do. I thought you had a web service that returns an object of a type, for instance, MyServerNameSpace.MyEntityType. I thought you wanted your client to receive it as MyServerNameSpace.MyEntityType instead of MyWebReference.MyEntityType.

If that is true, then just have your web service return MyServerNameSpace.MyEntityType, then find some hack to cause the proxy classes to use that type.

I suggest that you be careful, and get this working first with a single type. I've seen a great deal of confusion in developers who have tried to do this. That's why I recommend against it.

re: Webservice returns

Sat, 22 Sep 2007 07:50:47 Z

You are right. I originally wanted to return objects as MyServerNameSpace.MyEntityType instead of MyWebServiceReference.MyEntityType as this is how th current developers where I work have always done it and like it.

However, I am agree with the two of you that I should not do this. I already know that when you start using words like "hack" it is not a good start. On top of which trying to keep the generated files in sync will be a pain. I would rather just pass the "data" over the wire and leave it up to the client to deserialise the object.

I suppose the question i was asking before was really this:

Is the MyWebReference.MyEntityType result standard xml or should I deserialize the object manually on the server and pass it out?

eg:

publlic class CustomObject{}

public class MyWebService : WebService

{

[WebMethod]

public CustomObject GetAnObject()

{

return new CustomObject();
}

[WebMethod]

public string GetAnotherObject()

{

//serialize the object

string returnValue = MySerializer.Serialize(new CustomObject());

return returnValue;

}

Do you see? I can pass back as CustomObject or string or something else. I have worked with XML gateways which return you plain string which you decide how to instantiate. This is normally down to the caller to deserialize into a custom class.

Maybe I'm making more of this than i should. Could a NON .NET application understand the return value CustomObject? Would using string be more accessible?

re: Webservice returns

Sun, 23 Sep 2007 01:07:18 Z

You can go ahead and return CustomObject. The reason is that ASP.NET will do the serialization for you, and will do it in a way that any client will be able to understand.

On the client side, you can use the actual MyService.CustomObject, as long as you instantiate it from MyWebReference.CustomObject:

Code Snippet

using (MyWebReference.Service svc = new MyWebReference.Service())

{

MyWebReference.CustomObject mwrco = svc.WebMethod();

MyService.CustomObject msco = new MyService.CustomObject();

msco.Property1 = mwrco.Property1;

msco.Property2 = mwrco.Property2;

// or

// MyService.CustomObject msco = new MyService.CustomObject(mwrco); // but this is a little dangerous

}

re: Webservice returns

Mon, 24 Sep 2007 09:33:35 Z

Thanks People for you help. I messed around with it this morning and got a greater handle on what you guys were talking about.

I have decided to return the web reference types and deserialize them into the client side assembly types instead. Makes more sense to me that a web service provides the dat - essentially in xml - and it is up to the client to instantiate it into what ever the hell it wants to.

I use the XmlSerializer to serialize and deserialize depending on whether i am getting data or sending data. Does anyone see any problem with this?

Thanks again!

re: Webservice returns

Tue, 24 Jun 2008 13:27:10 Z

Humm... According to this: http://www.geeks.ltd.uk/Knowledgebase/Service-Object-Orientation.html: Object Orientation is about internals of a system, while Service Orientation is about external communication. OO is concerned about flexibility and abstraction, while SOA's concern is compliance with standards, simplicity and protocols.

Paymon