I agree that WSDL is always required. To a large degree I agree that the interop problems have been caused by incomplete implementations, and that the primary issue was caused by Microsoft's lack of xsi:type. But I still think it's valuable to have an actual Schema specification of the SOAP message body -- especially if you'd like to do message validation and/or transformation.
The main issue is this: there should be one standard way to encode a message -- not four. SOAP encoded was designed because XML Schema wasn't complete when SOAP 1.1 was published. Now that XML Schema is a standard, SOAP encoding is superfluous, and it just adds more work for the SOAP implementors to support two encoding schemes. And I don't see much value to the RPC style (particularly if you aren't using SOAP encoding). It causes a lot of confusion in terms of WSDL. I find it really objectional that the message style forces you to describe your WSDL messages differently. (With RPC style you must define your <part>s using the type= attribute, while Document style requires the element= attribute.) This situation reduces the reusability of a <portType>. Anne ----- Original Message ----- From: "Scott Nichol" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 19, 2003 12:32 PM Subject: Re: design question > 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. > >
