Matthew Graham wrote:
> 12. DIME: In Madrid, we agreed that we would deprecate DIME as it
> itself has long been deprecated. With the support for MTOM now in Axis
> 2, WSE, XFire, etc., I would rather that we suggest MTOM as the
> attachment mechanism. DIME is also incompatible with WS-Security so
> you cannot include a DIME attachment on a secure SOAP message.
Yes, we did agree that we would deprecate it, but we didn't set a
specific date.
I agree that we should use MTOM in preference to DIME, but as the list
of protocols is open, I don't see any harm in allowing it.
We (AstroGrid) would like to use Axis-2.x or XFire, and we are working
on migrating our services away from Axis-1.x.
However, at the moment, we are stuck with Axis-1.x, and so MTOM is out
of reach, at least for a while.
Based on the work we did for ADASS, using DIME attachments would give us a quick win for at least one authenticated secure put method we can all implement fairly quickly.
> Attachments are just another form of transport mechanism and I think
> we should keep messaging and transport separate so the import and
> export operations should not accept attachments: there should be
> separate endpoints for this as suggested in the spec.
I agree that DIME and MTOM should be treated as just another form of
transport mechanism.
However, I don't see any harm in allowing the PushDataTo and
PushDataFrom methods to accept attachments, as long as it is not part of
the main service specification or the WSDL.
As far as I know, allowing a DIME or MTOM attachment does not actually
change the WSDL ?
Guy has suggested that we should define the transport protocols in annexes (is that the right plural?) to the main document, making it clear that it is not a closed or mandatory list.
The document already has an annex that defines how to handle DIME
attachments.
I think we should split this into four annexes, one for each option (see
earlier email for details).
http://ivoa.net/forum/vospace/0606/0065.htm
We can add similar definitions for the equivalent MTOM forms as well.
Remember, this is not a mandatory or exclusive list, so having DIME defined in an annex does not mean an implementation _has_ to support it. All it means is that if you want to use DIME, or MTOM, and you want to talk to other VO services, then we recommend you use one of the methods defined in the annexes.
Note that calling a separate web service for a DIME or MTOM data
transfer means that the <location> element in the WSDL is no longer a
simple URL.
In order to specify _what_ data object to access in the other service,
we would need the service endpoint (URL) plus an additional service
specific identifier (string?).
This is a good reason for defining everything in the schema as
ComplexType(s) rather than just elements, and then using the individual
types to build the messages.
If we define the <location> or equivalent as a ComplexType that contains
a <url> element, then we should be able to define an xsd:extension that
adds the additional identifier element for an indirect DIME or MTOM
transfer.
Services that do support indirect DIME or MTOM should be able to
understand the xsd:extension type.
Services that don't support it should not receive messages with the
xsd:extension type in anyway.
Note - has anyone tried using xsi:type on an element to use an
xsd:extension type in a SOAP message ?
Dave Received on 2006-06-15Z04:13:14