tags:

views:

476

answers:

3

In WSDL file a function can return a Type or an Element. I have used only custom types as a results so far. However, I wonder when the Element should be more appropriate then the Type? What is the difference between them?

Is there any difference between

<wsdl:message name="MyFunction">
    <wsdl:part name="parameters" element="tns:Person"></wsdl:part>
</wsdl:message>

and

<wsdl:message name="MyFunction">
    <wsdl:part name="parameters" type="tns:Person"></wsdl:part>
</wsdl:message>

from a Client perspective (application that make use of the web service)?

The above question, as skaffman pointed, leads to a another question. What is the difference between

<xs:element name="Person" ... >
 ...
</xs:element>

and

<xs:complexType name="Person">
   ...
</xs:complexType>

?

+1  A: 

Which one you use depends on the schema to which it is referring. If tns:Person is defined in the schema as:

<xs:element name="Person" ... >
 ...
</xs:element>

Then you use

<wsdl:part name="parameters" element="tns:Person">

If, on the other hand, the schema is defined as

<xs:complexType name="Person">
   ...
</xs:complexType>

then you use

<wsdl:part name="parameters" type="tns:Person">

So the question is really what's the difference between Schema elements, and Schema types.

skaffman
Yes exactly, I would like to know when should I create a Schema type and when Schema element. Or, maybe in this context there is no difference?
czuk
You'd do better not to create either on your own until you know this stuff a bit better. In the meantime, depend on auto-generated WSDL and schema files.
John Saunders
+1  A: 
John Saunders
So, if I use a RPC-based service all my functions should return a Schema element?
czuk
I don't know. I don't use them. I find them problematic. I always use document/literal.
John Saunders
For document/literal the operation name is lost. I have a couple of functions with the same set of arguments so I cannot use document/literal. Despite this, have you ever used an Schema element as a function result?
czuk
I have no idea why you think you can't use document/literal. Got an example?
John Saunders
Let's say I have two functions int add(int a, int b) and int multiply(int a, int b). When client runs any of those two methods the same SOAP message is generated: [SOAP-ENV:Body>[a>1[/a>[b>2[/b>[/SOAP-ENV:Body> (I replaced all > with [ because they disappeared). The operation name is lost. For both operation the client will receive the same result because each time the first operation will be executed. So I could use document/literal only if I change the interface by merging the functions or discriminating their arguments.
czuk
No way. They'll be wrapped by an element based on the operation name. How'd you create these services? ASMX or WCF? Either way, I'll try it right now and show you. Maybe start a new question on this so we're not doing comments.
John Saunders
Just tried it. No problem. `<Envelope><Body><Add><a>1</a><b>2</b></Add></Body></Envelope>`. (Hint: surround inline code with ``)
John Saunders
That's strange. Are you sure you are using document/literal? According to this article http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ Listing 5 this is a rpc/literal message.
czuk
They gave a bad example. Mine has one part named parameters, which is an element named "Add", which is q sequence of x and y.
John Saunders
I see. Read on. Microsoft uses what they call "document/literal wrapped", as though there were something wrong with it. They then come close to lying when they say it's necessary to make an "educated guess". Nonsense. The message has a part which is an element which is of a type defined in the schema. The operation uses the message. No need to guess.
John Saunders
Ok, but "document/literal wrapped" is not the same as "document/literal". I thought you were talking about the second one. You can read in this article, that one of the weakness of the "document/literal" is "The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible."
czuk
Thank you for the long explanation. As I understand C# wrap the messages for document/literal by default, so there is no problem with the operation name. The situation is different in PHP. When using SoapClient the operation name is lost as it is stated in the referred article. My conclusion is that, document/literal in C# is in fact wrapped document/literal. In turn in PHP there is no difference. How in other languages? I do not know that.
czuk
A: 

I cannot comment on the WSDL part of the question, but I'll answer the XML Schema part.

<xs:complexType> defines a type, which describes content of an element, without describing the element itself (i.e. its name). <xs:element> describes an element (specifically its name), but not its type. However, <xs:element> always references the type for the content of the element it describes. This can be a reference to an existing type (including, but not limited to, <xs:complexType> - it can also be <xs:simpleType>, for example) definition elsewhere in the schema, or an inline <xs:complexType> definition:

<xs:element name="foo">
   <xs:complexType>
      ...
   </xs:complexType>
</xs:element>

Since the above construct is so common, you can actually omit <xs:complexType> entirely, and it will be implied.

As for whether you should always define types separately and then reference them in element declarations, or whether you should prefer defining element types inline within element declarations, it is a matter of style.

Pavel Minaev
According to skaffman a `complexType` can be named. So, what is the difference between naming the `complexType` and wrapping the type with an `element`?
czuk
If you name it, you can apply it to several different element declarations, and/or derive other types from it. So you can have complexType Person, derive complexType Employee from it by extension (adding more child elements to describe attributes), and then assign those types to elements "Person" and "Employee", for example.
Pavel Minaev