RE: [wsrp-markup] [wsrp][markup] DIME and one essential question

[Andre Kramer <andre.kramer@eu.citrix.com>]

I've no experience with attachments other than browsing the various 
specs and proposals but I thought the situation was somewhat worse
than this (and this is likely to be an understatement for the 
following reasons):

http://www.gotdotnet.com/team/xml_wsspecs/dime/WSDL-Extension-for-DIME.htm
proposes extensions to WSDL for DIME messages. A WSDL consuming tool 
that does not understand these extensions may fail the wsdl document, 
especially if the proposed XML Schema extensions are used to describe 
the MIME type, e.g. using the <content:mediaType type="image/jpeg"> 
as in the given examples. Such schema extensions, together with the 
proposed "ref:location" attribute, pollute the operation argument 
types which are a part of the "interface" sections of WSRP's wsdl. 
So, DIME appears to affect more than the binding parts of WSDL. 

Also, WSDL 1.1 has its own internal way to describe MIME type
encapsulation but only SOAP with attachments is facilitated by 
this. i.e. this extra wsdl mime binding information is silent 
about SOAP http transport / encapsulation issues.

In any case, WSDL 1.1. is under specified, each WS implementation having 
its own "style". Real interoperability, rather than one implementation 
accepting the usage styles of another, will not happen until efforts 
like the W3C's WSRP 1.2. are realized. It seems problematic to try to 
add DIME bindings and the above schema extensions to this WSDL 1.1. 
many-to-many special cased implementation mix.

Most WS tool chains use both the "interface" and "binding" parts to 
generate the client stubs so clients can't be coded independent of 
the specific binding to be used (Apache Axis docs mentions this issue).

DIME adds binary data to the HTTP content so firewalls may selectively
fail DIME encapsulated WSRP requests. A SOAP-with-attachments request
could be blocked by a firewall because it actually understood the 
multi-part mime content and decided a MIME type was dangerous. So, 
even from the point of view of the network the attachment "transports"
are not interchangeable.

Logically our interface arguments are different for the attachment and 
no-attachments cases. If attachments are used we have a single argument 
of binary type or some generic mime content type (with the attachment's 
mime type encoding the actual representation). For the no-attachment 
case, our signatures require two arguments (a generic one for the 
content, e.g. string or base64, and a second string arg specifying 
the content type).

For the no-attachments case, we also need some rules for efficient
encoding of the content. For example, can well structured XML mark-up 
be included as a literal document (requiring no encoding except proper 
name spacing), do we support escaping mark-up (where < becomes &lt;), 
or should base64 encoding always be used?

Therefore we should define the standard no-attachments wsdl for WSRP
interoperability and just allow producers and consumers to use their 
own (negotiated) alternative wsdl contracts. These can specify attachment 
usage or just real world variants on wsdl "style". The JAX-RPC SOAP- 
with-attachment alternative contract should be fairly ubiquitous,
while the DIME ones may be in much flux until WSDL standardization has 
caught up.

regards,
Andre

-----Original Message-----
From: Carsten Leue [mailto:cleue@de.ibm.com]
Sent: 12 August 2002 16:37
To: wsrp-markup@lists.oasis-open.org
Subject: [wsrp-markup] [wsrp][markup] DIME and one essential question


I wanted to follow up with a short comparison of DIME vs SOAP attachments.
One of us - Richard Cieply - did this, I appended the results to this
email.

My summary would be that the use of any kind of attachments would not show
up in the WSDL definition of the interface but only in the binding
information. I.e. that the choice will not directly affect the
specification.
However this raises another question: to what level do we want to specify
WSRP? Just the interfaces or also the bindings?
If we only define the interfaces and not the binding then the consumer
would need to generate (on the fly) a proxy for each remote sevice as the
binding might be different, e.g. one producer decides to marshal the markup
over an attachment another does not. The interface would not be affected
thus the producer a WSRP compliant producer. However this would not really
be plug-and-play, at least not from my understanding. I assumed that it
would be possible to write a "static" proxy that consumes all WSRP
compliant WS. With different bindings that would not be possible.

What is the opinion of the group?


Writeup DIME vs SOAP Attachments by Richard Cieply.

1. 'Politics'
Soap Attachments are specified by the W3C and supported by Apache SOAP and
Axis.
Dime is currently in the Internet Draft phase and I suppose it to become a
RFC sooner or later.
Currently the MS SOAP Toolkit Version 3.0 supports DIME (and only DIME).
Also Axis states to support DIME with its beta3. The API doc specifies some
Classes in the org.apache.axis.attachment package to generate DIME
multipart messages.
Microsoft states that it will concentrate on DIME, it seems to me that they
will not be supporting SOAP Attachments in their .NET.
Here is a cite from their website:
"In the end, the MIME approach to sending SOAP messages with attachments is
a technically plausible solution. However, supporting multiple
specifications for achieving the same results is costly and potentially
confusing. Due to its technical superiority, Microsoft will be motivated to
focus on DIME for binary attachments in its future SOAP tools and
platforms."
and
"DIME is a major part of Microsoft's future SOAP and XML Web Service
strategy "

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/h
tml/service01152002.asp

2. Dependency on SOAP
I'm not sure if I understood this question correctly.
SOAP Attachments define a means to transport SOAP messages via MIME
multipart/related messages in a way preserving processing a SOAP message as
defined in the SOAP1.1 spec.
I'm not to deep into the DIME stuff but as far as I understood their
examples DIME is a replacement for MIME multipart/related messages. DIME
messages may CONTAIN SOAP messages.
Thus both are independant on SOAP.

I think the other way around the question is more interessting: Does any of
these encodings affect SOAP?
I'd say 'no' here either.
The well known and in SOAP1.1 defined 'href' is used to address a part of a
MIME multipart/related or DIME message. It is the task of the SOAP
implementation to retrieve these parts from that message.
The lingo of SOAP is not affected here.
As I said above Axis states to implement both MIME mp/rel and DIME,
Microsoft SOAP Toolkit 3.0 implements only DIME.

3. Effects on the wsdl
The question here is if the usage of one of the above attachment types will
affect our wsdl, say if types/interfaces would change if we prefered the
one or the other.
Generally the types/messages/port types are not affected by this.
It is part of the binding definition to say how the data will be carried on
the transport level.
The WSDL1.1 spec contains a MIME binding schema.
I haven't figured out yet how a DIME binding looks like - I have to check
this later.

However, whether to use DIME or MIME mp/rel is defined in the binding, so I
assume the interfaces  would remain the same (say the types/messages/port
types).
So I would say it is up to the implementations to choose the right way and
transport.

From the WSRP point of view it seems to me that we don't need to define
anything about this in the protocol as it is a transport choice.
We could recommend to use DIME because it looks like this is the one which
will be supported by both worlds in the future J2EE and .NET.

Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



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