Paul Harrison wrote:
> 3. DIME transfers - the 0.21 spec mentions a usage of DIME that
> implies that there should be a specific operation that the files
> could be attached to, and by implication this operation should be in
> the interface definition. This was not how I would have envisaged
> DIME working if we allow it as a transport, as it loses the principal
> advantage of attachments anyway, i.e. that the HTTP SOAP call with
> all the necessary data is atomic and synchronous. Would it not be
> better to say that if DIME is specified as a transport then the data
> be attached to the pullDataFromVoSpace or pullDataToVoSpace calls
> themselves?
I agree, we should have both, plus leave it open to include others in the future.
Initially, there are two ways that we could use DIME and MTOM attachments. The first is to send the data as an attachment to the VOSpace message or response, as you describe above.
The second is to send the data via a separate SOAP message (I know, not optimal, but there may be cases where this makes sense). This requires details of the receiving web service, the WSDL, the endpoint, and possibly some form of service specific identifier. An example of this would be the original VOStore get and put methods we demonstrated at ADASS.
We can distinguish between the different forms by defining different a protocol URI for each one.
ivo://...../vospace.01.00.dime.put
This VOSpace protocol sends the data to the target service as a DIME
attachment to the PullDataToVoSpace method.
To use this transfer method, the <protocol> element should be set to
this URI, and the <location> element is empty (the data is already
attached to the SOAP message).
ivo://...../vospace.01.00.dime.get
This VOSpace protocol sends the data to the client as a DIME attachment
to the PushDataFromVoSpace method.
To use this transfer method, the <protocol> element should be set to
this URI, and the <location> element is empty (the data will be attached
to the SOAP response).
ivo://...../vostore.01.00.dime.get
This VOSpace protocol gets the data from a separate web service that
supports the original VOStore get method.
To use this transfer method, the <protocol> element should be set to
this URI, and the <location> element should be set to the endpoint of
the target web service.
Note - this may need an additional element in the VOSpace message to
supply some form of path or identifier to specify what data to get from
the target service.
ivo://...../vostore.01.00.dime.put
This VOSpace protocol sends the data to a separate web service that
supports the original VOStore put method.
To use this transfer method, the <protocol> element should be set to
this URI, and the <location> element should be set to the endpoint of
the target web service.
Note - this may need an additional element in the VOSpace message to
supply some form of path or identifier to specify where to put the data
within the target service.
ivo://...../other.project.dime.get
This VOSpace protocol gets the data from a separate web service that
supports <new type of DIME get service>.
To use this transfer method, the <protocol> element should be set to
this URI, and the <location> element should be set to the endpoint of
the target web service.
Note - this may need an additional element in the VOSpace message to
supply some form of identifier.
Using a different protocol URI for each of the different forms means
that all of these can be listed in the capabilities of the particular
VOSpace service.
The first two (attaching the data to the VOSpace messages) means we have
a simple way to implement DIME get and put for a VOSpace service.
However, it does not mandate this as the only way of using DIME and
MTOM, leaving things open for others to provide different web service
interfaces is they want.
If a different Grid project already have their own DIME or MTOM
implementation, if they add a new protocol URI that describes their
interface, we can create VOSpace clients that can send and receive data
from their services too.
Note that the indirect forms of DIME get and put may need an additional
element in the VOSpace message to supply some form of identifier.
Could we handle this by defining the <protocol> or <location> elements
as a ComplexType, and then using xsi:type to replace it with extended
forms when the protocol requires it.
Another example of this would be FTP or HTTP transfers with unusual
authentication methods may need separate name and password elements if
they can't be encoded in the URL.
A service should only receive messages with the extended type if they
have listed that particular protocol in their capabilities.
If the protocol isn't listed in the service capabilities, then it should
reject the message anyway.
Dave Received on 2006-06-14Z14:47:49