Are you talking about rpc/encoded messages in the absence of WSDL? If there is WSDL for the service, are there still ambiguities? My impression (and experience) is that if I have WSDL for a service, and both endpoints have WSDL support, I have pretty much the same degreee of interop for either rpc/encoded or doc/lit. In the absence of WSDL, doc/lit is useless, while at least most implementations can make sense of many rpc/encoded messages.
Basically, my impression is that the metadata provided in WSDL is more important to interop than the choice of rpc/encoded v. doc/lit itself. On 18 Jun 2003 at 23:17, Anne Thomas Manes wrote: > Doc/lit doesn't define type mappings, but it definitively specifies the > structure of the message via XML Schema. Because the two applications know > in advance exactly what the message structure is, the details of how the > SOAP message processor maps the XML Schema to language types doesn't matter > to the other application. When using rpc/encoded, the two applications have > not agreed to a specific message structure. The SOAP message processor > generates the SOAP message structure based on it's specific interpretation > of SOAP Section 5, and there's no definitive schema of the message. The > interoperability issues arise when two different SOAP message procesors > interpret SOAP Section 5 slightly differently. > > Anne > > ----- Original Message ----- > From: "Scott Nichol" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 18, 2003 3:18 PM > Subject: Re: design question > > > > 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. > > > > > > Scott Nichol Do not reply directly to this e-mail address, as it is filtered to only receive e-mail from specific mailing lists.
