I agree that the WSDL for doc/lit is indeed less obtuse than that for rpc/encoded.
On 19 Jun 2003 at 13:31, Anne Thomas Manes wrote: > 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. > > > > > > Scott Nichol Do not reply directly to this e-mail address, as it is filtered to only receive e-mail from specific mailing lists.
