> I don't concur with you on thing you mentioned below in the first paragraph. If you > factor interoperability & infrastructure issues in, your design would be definitely > affected accordingly. If your service is going to be consumed by a VB6 client or > .net client (or any non-java consumer), RPC/literal is not the right solution. In that case, the service should be designed to use Doc/literal. Also, RPC/Encoding is not always the right design for interopetability reasons. I had my original service return a DOM element and due to interoperability reasons, I turned in to RPC/Encoding type that returns a String containing XML representation.
Most SOAP implementations interoperate well (not necessarily perfectly) using rpc/encoded, although WS-Interop has made doc/lit the preferred representation. VB6 clients interop well with Apache SOAP services, if you either (1) use the SOAP Toolkit low-level API, or (2) change simple types within the WSDL to xsd:anyType, which forces the SOAP Toolkit to emit xsi:type attributes for the affected elements. There are some popular niche SOAP implementations, such as NuSOAP, that work better with rpc/encoded than doc/lit. And, of course, Apache SOAP itself is more-or-less based on an rpc/encoded world. For your service returning a DOM element, regardless of whether you wanted to use rpc/encoded or doc/lit, you would need to either (1) write a deserializer on the client or (2) write WSDL that describes the structure of the XML representing the element. These are both ways of determining how to deserialize the returned value on the client. This is a general interoperability issue, not restricted to the use of a DOM element: how does one end of the conversation make sense of the envelope it receives from the other end. You can get great interoperability by restricting yourself to the simple types from the XML Schema spec. When you want to use other types, you need a mechanism for both ends to agree upon the structure of the information, which is one of the purposes of WSDL. > Are there any "smart SOAP runtime" that provides validation using schema ? There may be one or more, but I have to say that I do not know of any. In .NET 1.1, you would do validation through a SOAP Extension. It is not as simple as specifying an attribute or setting a flag somewhere. True validation against a schema is not built-in. The extension receives a copy of the XML to do with what it pleases. At this point, your code uses the XML parser to validate it, presumably throwing an exception if there is a problem. I cannot tell from the web site whether GLUE (http://www.themindelectric/) or WASP (http://www.systinet.com/) does validation. They are two of the premier Java implementations of web services. As described by Anne, in Axis, you could just hook another processor in the chain to do validation, which is much like the .NET SOAP extension method. Of course, in order to de-serialize the XML document in the SOAP envelope, binding it to language variables, the XML must be at least pretty darn close to valid. For example, an element cannot enclose string data and successfully de-serialize into an int. The biggest thing I can think of that XML validation would check that de- serialization would not have to is domain checking for XML types defined by restriction. If my schema has a type that is an int restricted to the values 1, 2 and 3, de-serialization will probably work for any integer, so out-of-range values would pass through. Scott Nichol Do not reply directly to this e-mail address, as it is filtered to only receive e-mail from specific mailing lists.
