Hello,
From 'SOAP Version 1.2 Part 2: Adjuncts'
(http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#soapforrpc) :
"use and implementation of the SOAP RPC Representation is OPTIONAL."
I have read a number of articles recently that predict a strong trend away
from RPC. However, reality does not always follow predictions.
Take care.
Joe
-----Original Message-----
From: Richard Cieply [mailto:]
Sent: Tuesday, September 24, 2002 10:08 AM
To: Andre Kramer
Cc:
Subject: RE: [wsrp-wsia] [I#93] Payload extensibility mechanism
Yes you are right.
I did some testing around document/literal with AXIS and .NET and both were
able to generate proxies/stubs.
As you said the question is whether to use style=document | RPC and
use=encoded | literal.
It's hard to find out what is used more often on the net.
Depending on the articles some see a heavier document/literal some
RPC/encoded and others 50/50 usage.
I think this is quite a philosophic question.
RPC style thinks in terms of method invocation and to provide these remote
procedure calls transparently to the client.
Section 5 allows a model in which the service provider doesn't have to
incorporate an XML parser , navigate DOM trees, etc.
The framework/soap stack takes care of encoding/decoding and there is no
effort for the author required - this seems to be the idea here.
On the other hand there is the document style which thinks of exchanging
XML documents as the payload of a SOAP message.
This is more of thinking in terms of messaging.
Document/literal goes away from the complexity of section 5 encoding.
But this shifts responsibility to the application level in dealing with the
message. An XML parser is needed, schema validation etc.
This aproach seems to allow for the use of sophisticated XML applications
and processing models.
From the interoperability point of view it seems to me that
document/literal gains advantage here.
Some words to the complexity of document/literal:
It showed that .NET and AXIS provide a framework which relieves the service
author from dealing with XML parsers etc.
Both were able to generate "dataholder" or bean-like classes for the types
defined in the schema. Also appropriate interfaces/proxies/stubs
were generated which gave the same handling to the author as in the RPC
style case. Both XML handling and SOAP were hidden from the author.
So the advantage from this point of view of RPC/section 5 seems to melt
here.
I found some statements on the net saying that style=document MUST be
supported if using SOAP 1.1 while RPC is optional.
However I haven't find the evidence for that in the specs.
Has somebody done more detailed reading and can confirm this?
.NET does document/literal by default. One has to switch on RPC/encoded.
UDDI does also document/literal.
JAX RPC states that an implementation MUST support document/literal and
RPC/encoded, while document/encoded and RPC/literal are optional.
AXIS uses RPC/encoded as default, but as showed support document/literal.
So for me the question reduces to two options: document/literal or
RPC/encoded.
For me document/literal seems to be better concerning interoperability,
because one can opt to simply use an XML parser/generator.
It allows for the <any... /> extensibilty mechanism.
The complexity of dealing with XML documents on the application level seems
to be reduced by the frameworks like .NET and AXIS - they hide this
handling.
RPC/encoded defines a model on how to do serialization/deserialization and
adds more details to the messages which can be used by the stacks to
serialize/deserialize. Using these stacks reduces the complexity of dealing
with XML documents.
What are your opinions?
Mit freundlichen Gruessen / best regards,
Richard Cieply
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 09/19/2002 01:21 |
| | PM |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
|
|
| To:
|
| cc:
|
| Subject: RE: [wsrp-wsia] [I#93] Payload extensibility mechanism
|
|
|
|
|
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
In order to use <any namespace="##other"/> we would need to switch
to "document style" for our wsdl (with literal encoding).
A quick check against the attached service1.wsdl showed that
.NET and Axis compiled this test ok but Sun's JAXRPC gave up and
passed everything as an javax.xml.soap.SOAPElement blob.
The question then becomes one of XML extensibility versus using
SOAP rpc encoding style. [Document style would also facilitate
returning XML markup within the getMarkup response "document" -
but I see many arguments for sticking with Section 5 SOAP Encoding.]
-----Original Message-----
From: Gil Tayar [mailto:]
Sent: 19 September 2002 06:47
To:
Subject: [wsrp-wsia] [I#93] Payload extensibility mechanism
Topic: interface
Class: Minor Technical
Title: Payload extensibility mechanism
Document Section: throughout
Description:
Current draft spec uses Property[] as a payload extension mechanism. At the
F2F we decided to explore changing this to the <any/> mechanism of schema.
Richard Cieply did some testing based on the working demo he showed and
some exploration around the relevant specs. His writeup:
Here is a short summary about the <any> support in WSDL and the SOAP
stacks.
WSDL spec 1.1 and 1.2 doesn't mention the <any> XML extension and how to
deal with it.
However it states that WSDL prefers XSD as the canonical type system.
XSD defines the <any> wild card.
SOAP 1.1 spec states that it defines a narrower set of rules for
encoding data (than XML does).
Section 5 defines some value, simple value, compound value, array,
struct, simple type, compound type.
However this deals with how content must be encoded in a SOAP message.
For the <any> case one would exchange this wildcard with actual content
which follows the spec, i.e. one can not say whether <any> is supported
or not.
JAX RPC has an XML schema support appendix and states that any XML data
types not listed in this section are not required to be supported.
How to deal with <any> is not mentioned here.
I made some testing with AXIS and .NET
created a WSDL extending a complex type (DataItem) with <any
namespace="##other"/>
(See attached file: echo.wsdl)
used AXIS' WSDL2Java to generate the server side stub
AXIS created a field named _any to DataItem with type
org.apache.axis.message.MessageElement [ ]
created a client side wsdl which replaced the <any> element with some
additional elements to get a client proxy which sends addtional data
in DataItem in the soap message
(See attached file: echoclient.wsdl)
communication between client and server worked as expected
the addtional elements were accessible by means of the MessageElement
[ ] on the server side. Of course this would also work vice versa.
MS Visual Studion .NET failed to generate proxies on a WSDL
containing <any> with no error message. Simply no code was generated
at all.
WSDL.exe from the .netFrameworkSDK failed saying that any is not
allowed in the WSDL.
I could not find any statement saying whether .net should support
<any> in WSDL or not
However a .net server accepts a soap message which contains
additional elements compared to the ones defined in the wsdl (as
expected).
There should be a way to access the complete soap message from .net.
So there might be a workaround by simply dropping the <any> elements
in the WSDL (when creating a service from a WSDL) and access the soap
message to obtain the addtional data sent by the client (not tried).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Discussion:
#### service1.wsdl has been removed from this note on September 24 2002 by
Richard Cieply
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
