|
That's the problem with RPC/Literal. Very few
platforms support it. That's likely to change in the future, because WS-I Basic
Profile requires support for RPC/Literal. But for now, it's a big
issue.
I think you'll find it very difficult to create an
interoperable doc/literal service using Apache SOAP 2.2 (although perhaps Scott
can give you some pointers on how to make it work). I'd suggest that you stick
with RPC/encoded in this situation (unless you're free to upgrade the SOAP
engine in WAS). And I suggest you use PocketSOAP for your client rather than MS
SOAP Toolkit.
Anne
----- Original Message -----
Sent: Thursday, June 19, 2003 7:49
PM
Subject: Re: design question
Thanks Anne.. My original service was of an
RPC/Literal style (it returned a DOM element) and worked fine within Java
environment...Then came a requirement to consume it from a VB 6 client
and all sort of interoperability issues started cropping up... Since, I'm
stuck with infrastructure limitations, I decided to turn my service to
RPC/Encoded by returing an XML string.. Modified my code to return an XML
string in stead of a DOM element...
I've not yet created a doc/literal style service, but
soon try to do so..
Thanks everybody who replied to my emails..
Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
Vishal,
Your
response implies that you expect doc/literal to deliver the SOAP body
to
the service as XML. I think this is your source of misunderstanding.
A
SOAP message processor normally transforms the SOAP body into
language
objects -- it doesn't matter whether you use rpc/encoded or
doc/literal.
(assuming that your SOAP message processor supports both
styles). Hence the
application won't have to validate the message. To a
large extent, the SOAP
message processor validates the specific
information in the message during
the type mapping process, although it
isn't a formal validation process.
You're correct that Apache SOAP
2.2 doesn't directly support doc/literal. So
I don't understand why
you're trying to create a doc/literal service. You
have an rpc/encoded
service. Therefore you need to create a WSDL file that
describes that
rpc/encoded service. (You can use Axis java2wsdl for that.)
If you
attempt to defined the WSDL as a doc/literal service, your SOAP
server
would reject any messages based on that WSDL.
MS SOAP Toolkit
supports rpc/encoded. See Scott's last email for
interop
guidelines.
You're other option is to upgrade the SOAP
platform in your WAS 403 system.
I'm pretty sure that GLUE can run in WAS
403.
Anne
----- Original Message -----
From: Vishal
Shah
To: [EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 3:01
PM
Subject: Re: design question
Pl see my response
below..
Anne Thomas Manes <[EMAIL PROTECTED]>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 requi
rements 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: [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!
Do you Yahoo!?
SBC Yahoo! DSL -
Now only $29.95 per month!
Do you Yahoo!?
SBC
Yahoo! DSL - Now only $29.95 per month!
|
