1.0rc1 WSDL issues

[Dave Morris]

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