One more comment. I consider it out of the ordinary for the code implementing a service method to manipulate XML in any way. As such, your method that returns a DOM element seems quite odd to me. One typically uses constructs more native to the implementation language, such as a class instance or any array. The SOAP engine then serializes this as XML for you, just as it deserializes parameters passed to your method.
On 18 Jun 2003 at 15:13, Scott Nichol wrote: > > 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. > > > Scott Nichol Do not reply directly to this e-mail address, as it is filtered to only receive e-mail from specific mailing lists.
