In what way does doc/lit define language type mappings? I've never really understood why doc/lit is better than rpc/encoded. If you have no WSDL, you have problems with complex types either way. If you do have WSDL, you have XML type information either way, and I don't see why you would bind any differently. I've seen the merits of doc/lit v. rpc/encoded discussed in various places, but never understood any type mapping advantage.
On 18 Jun 2003 at 13:20, Anne Thomas Manes wrote: > From my perspective you should always use Doc/literal. SOAP Encoding has been the > source of many interoperability issues, because the mechanism of mapping language > types isn't defined concretely by SOAP Section 5. Hence you should always use > literal encoding. And many implementations don't support RPC/Literal. > > I'm not sure why you found it necessary to use RPC/encoded in order to get the SOAP > deserializer to return a string. You should be able to make that happen using > Doc/Literal, if that's what you want -- the serialization requirements should be > specified in the deployment descriptor. > > I don't think that any SOAP engines do automatic schema validation (there's > sufficient overhead associated with the process that you wouldn't want to do it by > default). But many of the commercial implementations provide typed interceptors that > make it simple to request validation (sometimes just by declaring a deployment option). > > Anne > ----- Original Message ----- > From: Vishal Shah > To: [EMAIL PROTECTED] > Sent: Wednesday, June 18, 2003 10:58 AM > Subject: Re: design question > > > Thanks Anne for elucidating. I'm stuck with the legacy system and infrastructure > that supports it.. I need to find a clumsy way to get around to make things work.. > > 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. > > Are there any "smart SOAP runtime" that provides validation using schema ? > > Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > Vishal, > > A SOAP runtime system should provide a layer of abstraction between your message > format and the application that implements the service. Hence the format of the > message (Doc/literal vs RPC/encoded) shouldn't really impact the design of your > service. The SOAP runtime system should be able to marshal and unmarshal the messages, map XML to Java, dispatch the appropriate application, and transform exceptions into SOAP fault messages for you -- all based on the WSDL description and deployment descriptor -- regardless of whether you use RPC or document style messages. Your application shouldn't need to process XML unless you choose to receive the message as an XML document. > > You should not assume that the SOAP runtime will validate the document. If you > want it to perform validation before processing, you would need to specify a > validation interceptor in your deployment descriptor (to call a handler in your > handler chain). You should assume that the SOAP runtime will parse the document and deserialize it into Java objects. If you are using RPC/encoded, then it does the mapping based on the SOAP Section 5 data model. If you are using Document/Literal, then it does the mapping based on the XML Schema message description. > > When writing a service, you should do what you would normally do in any Java > application -- throw an exception. The SOAP runtime system should catch the > exception and transform it into the appropriate SOAP fault message. The client SOAP > runtime system should be able to interpret the SOAP fault, and assuming it's a Java system, rethrow the exception for the client. > > Now, of course, these best practices don't necessarily apply to Web services > written using Apache SOAP. You must realise that Apache SOAP is a very old SOAP > implementation that doesn't support WSDL, is very RPC/encoded-centric, and doesn't > support doc/literal according to the standard. > > Unless you have legacy applications based on Apache SOAP, I recommend that you > start using Apache Axis (http://ws.apache.org/axis), or any of the 20 or so > commercial implementations that fully support SOAP 1.1, WSDL 1.1, JAX-RPC, and the > WS-I Basic Profile. > > Best regards, > Anne > > ----- Original Message ----- > From: Vishal Shah > To: [EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 10:59 AM > Subject: design question > > > Hi, > > I've a couple of design questions...I've a Doc/literal style service.. > > What's the best way to handle any abnormal conditions and errors ?Should the > service throw an exception or should it create a "error" element in a response > document ? > > Is it safe to assume that in Doc/literal style, a doc gets parsed and > validated using a schema ? If not, is the service responsible for validating > (coarse-grained validation) the document ? Pl advise... > > Thanks > VS > > > > -------------------------------------------------------------------------- > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > > > ------------------------------------------------------------------------------ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > Scott Nichol Do not reply directly to this e-mail address, as it is filtered to only receive e-mail from specific mailing lists.
