ws-soap-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vishal Shah <sha...@yahoo.com>
Subject Re: design question
Date Wed, 18 Jun 2003 19:01:37 GMT
Pl see my response below..

Anne Thomas Manes <anne@manes.net> wrote:From my perspective you should always use Doc/literal.
I agree with you..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'm using WAS 403 (supports Apache SOAP 2.2) and I don't think it directly supports Doc/literal
type. My understanding is, need to use Apache 2.3 to use doc/literal.. unless I'm missing
something.. Again, the issue is interoperability.. since I need to provide WSDL to my VB client
and I don't know a way to create a WSDL doc for a doc/literal type service...
 
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). Yes, I envisioned it that way.. The automatic schema
validation thing would add in some overheads, but I feel that service (actual implementation)
should be freed up from coarse-grained validation and the abstraction layer should be responsible
for validating incoming request. As a result, the service can focus on its core processing...
 
Anne
----- Original Message ----- 
From: Vishal Shah 
To: soap-user@ws.apache.org 
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 <anne@manes.net> 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: soap-user@ws.apache.org 
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!


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
Mime
View raw message