OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp-wsia] [I#93] Payload extensibility mechanism

rpc/literal is optional for JAX-RPC (By the way: great analysis Richard!) 
so I would only contemplate a switch to document/literal (see below). 
I supposed this was basically a question of timing as, in theory, 
rpc/encoded allows for simple SOAP implementations to use WSRP 1.0,
but that we would switch over to document style eventually (2.0?).

Are there any other arguments / opinions, other than on extensibility
that would add more weight to document style for 1.0? It would allow
XML markup (but not HTML) to be carried in the same efficient way as 
extensibility elements.


(When I say "in theory": http://www.oreillynet.com/pub/wlg/2042,
the complex current wsdl and what Ugo tell us about WS-I.org)

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: 24 September 2002 17:58
To: 'Rudnicki Joseph G CONT NSSC'; 'Richard Cieply'; Andre Kramer
Cc: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#93] Payload extensibility mechanism

Just another piece of information: the WS-Interoperability organization does
not support SOAP encoding in its Basic Profile. Only literal encoding is
supported (and both RPC style and document style are supported). I also
agree that the current trend is away from the RPC style and in favor of the
document style.


-----Original Message-----
From: Rudnicki Joseph G CONT NSSC [mailto:RudnickiJG@NAVSEA.NAVY.MIL]
Sent: Tuesday, September 24, 2002 7:44 AM
To: 'Richard Cieply'; Andre Kramer
Cc: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#93] Payload extensibility mechanism


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.


-----Original Message-----
From: Richard Cieply [mailto:CIEPLY@de.ibm.com]
Sent: Tuesday, September 24, 2002 10:08 AM
To: Andre Kramer
Cc: wsrp-wsia@lists.oasis-open.org
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

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
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
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:cieply@de.ibm.com

|         |           Andre Kramer     |
|         |           <andre.kramer@eu.|
|         |           citrix.com>      |
|         |                            |
|         |           09/19/2002 01:21 |
|         |           PM               |
|         |                            |
  |       To:       wsrp-wsia@lists.oasis-open.org
  |       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:Gil.Tayar@webcollage.com]
Sent: 19 September 2002 06:47
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] [I#93] Payload extensibility mechanism

Topic:  interface
Class:  Minor Technical
Title:  Payload extensibility mechanism
Document Section: throughout
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

   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
      (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
      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).

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

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC