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 -----
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 -----
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!
|