Forum OpenACS Q&A: Re: Which version of xotcl-soap (xosoap) should I use?

22: Re: Which version of xotcl-soap (xosoap) should I use? (response to 21)

Posted by Tom Jackson on 01/01/08 11:51 PM

I'm talking about WSDL, which is a standard for describing a web service. Anyone who wishes to pick up a web service client have have it 'understand' the web service automatically should know that there are limits on when this can be done. The term for this understanding is interoperability. And it means that there are no ambiguous features in the description.

However, even WSDL is a pretty loose standard. I've pointed out before that an easier standard to follow is the WS-I Basic Profile:

http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html

Maybe you think I'm talking about how you translate an existing interface into a web service? Not sure, but the issue is a client issue, not a server issue. WSDL is used to abstract the interface away from the programming language used on the server. Otherwise, consuming an Axis service would require an Axis client, ruling out the use of OpenACS, C# or any other client. One of the main problems for interoperability with web services is their continued tie to the RPC style. It is easy to implement because it is based upon mapping programming types to a message format. Assuming client and server are based upon the same programming language, this is easy, but it isn't interoperable outside these rigid and narrow limits.

In the present case we have an Axis based service. The service is defined using a WSDL. My assumption was that the client should automatically read and understand the definition so that it can construct client API to invoke the operations. When the data is transfered as element content only, it is easier to create client API. In this case the parent could be considered a class or an object, and the child elements are slots, or whatever the correct word would be for the language. If you add attributes, there is an ambiguous quality. Without human analysis, you can't determine if the element attribute is logically part of the element data, or a comment on the data itself. For instance, the element content could be encoded, so an attribute could be targeted at the serializer/deserializer code and not the application.

This is, again, the easy case: data element have attributes. The hard case is a WSDL which has extensions. Who could ever provide a client which understood private extensions automatically, without hand coding? Nobody, outside the narrow meaning of the basic WSDL, very little can or should have a fixed meaning.

25: Re: Which version of xotcl-soap (xosoap) should I use? (response to 22)

Posted by Stefan Sobernig on 01/02/08 09:30 AM

Tom,

If you add attributes, there is an ambiguous quality. Without human analysis, you can't determine if the element attribute is logically part of the element data, or a comment on the data itself. For instance, the element content could be encoded, so an attribute could be targeted at the serializer/deserializer code and not the application.

Again, this is what I referred to as "content-/ document-model-first" versus "language-construct-first" (or, schema-first versus object-first). It depends on your scenario and the set of requirements embodied in coded conventions. Justis' WSDLs are auto-generated by Axis which implies an object-first simplification. For the resulting Java objects, it does not make any difference whether an object member (i.e. property or slot in XOTcl terms) is transmitted as element or element attribute. That is, in object-first scenarios, there is hardly any quality difference between element and attribute content because the underlying object systems does not make these distinctions.

Your statement is certainly valid but only for schema-first scenarios, where we cannot stream-line schema information in the meta-object level of an object system. But this is certainly NOT an issue with Justis' WSDLs ...

Without human analysis, you can't determine if the element attribute is logically part of the element data, or a comment on the data itself. For instance, the element content could be encoded, so an attribute could be targeted at the serializer/deserializer code and not the application.

Again, you refer to something which does not concern Justis' WSDLs at all. In Document/Literal style, document content is not "encoded" as it would be with SOAP Encoding or whatsoever. It is a proper document that can be thrown against any XML schema.