Reply to thread

Message

This is definitely the right way to go. For WCF this is called a "operation contract".

There is no need to define a new protocol based on a text string. WCF is doing this in the background: It converts all parameters of a call to a XML message using SOAP format (which actualy produces a simple string containing XML)

On the client side you can create a proxy class by using a WCF tool that contains a method for each Web Service method.

You can also reference a asembly containing the interface definition on both sides (client and server). In this case you will have a stronger coupling between Client and Server. You can use complex .NET types like DataSet, Guid, ArrayList or List<> but loose compatibility. E. g. a Unix system will not be able to consume/understand a .NET DataSet-Object. When using compelex types this approach is more "Remoting" than "Web Service" like.

For best compatibility you schould only use intrinsic types like int, string or double in the interface definition. User defined complex types must be attibuted as "Data contract" and schould contain only intrinsic types to get 100% Web Service compatibility.

Regards,
Christoph

<blockquote data-quote="chrispi" data-source="post: 126209" data-attributes="member: 20307">This is definitely the right way to go. For WCF this is called a &quot;operation contract&quot;.There is no need to define a new protocol based on a text string. WCF is doing this in the background: It converts all parameters of a call to a XML message using SOAP format (which actualy produces a simple string containing XML) On the client side you can create a proxy class by using a WCF tool that contains a method for each Web Service method.You can also reference a asembly containing the interface definition on both sides (client and server). In this case you will have a stronger coupling between Client and Server. You can use complex .NET types like DataSet, Guid, ArrayList or List&lt;&gt; but loose compatibility. E. g. a Unix system will not be able to consume/understand a .NET DataSet-Object. When using compelex types this approach is more &quot;Remoting&quot; than &quot;Web Service&quot; like.For best compatibility you schould only use intrinsic types like int, string or double in the interface definition. User defined complex types must be attibuted as &quot;Data contract&quot; and schould contain only intrinsic types to get 100% Web Service compatibility.Regards,Christoph</blockquote>

[QUOTE="chrispi, post: 126209, member: 20307"] This is definitely the right way to go. For WCF this is called a "operation contract". There is no need to define a new protocol based on a text string. WCF is doing this in the background: It converts all parameters of a call to a XML message using SOAP format (which actualy produces a simple string containing XML) On the client side you can create a proxy class by using a WCF tool that contains a method for each Web Service method. You can also reference a asembly containing the interface definition on both sides (client and server). In this case you will have a stronger coupling between Client and Server. You can use complex .NET types like DataSet, Guid, ArrayList or List<> but loose compatibility. E. g. a Unix system will not be able to consume/understand a .NET DataSet-Object. When using compelex types this approach is more "Remoting" than "Web Service" like. For best compatibility you schould only use intrinsic types like int, string or double in the interface definition. User defined complex types must be attibuted as "Data contract" and schould contain only intrinsic types to get 100% Web Service compatibility. Regards, Christoph [/QUOTE]