Yes, I definitely concur with you on the note that there should be actual schema specification of the SOAP msg body. My understanding is that Doc/lit is the only real approach going forward according to WS-I guidelines.. In order to have enterprise-class web service, we need to have common standards for interoperability and a programming model should be decoupled from the SOAP msg format.
Vishal
Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
Anne Thomas Manes <[EMAIL PROTECTED]> 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 yours
using the type= attribute, while Document style requires the element=
attribute.) This situation reduces the reusability of a.
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.
>
>
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
