Subject: RE: [trans-ws] Attachments v URI
I have not had a chance to really discuss this with our relevant developers yet, as they are in the middle of an important release, but I will have time to talk to them next week.
Personally I like the flexibility of the URLs but I’m concerned about added implementation complexity. If URIs may point to anywhere an implementation with automated processing would need to be able to access those URLs during processing. The specification today does not require the implementation to have internet access. (The web service portal of course needs to be exposed, but the implementation does not need to be accessing the internet. (I.e. currently we have only one way communication, while if we use URLs we will need two way communication.)
Complexity is also added when it comes to processing that requires updating a resource, and the lifetime of the URLs get very difficult to manage.
My gut feeling is that the added complexity could be scaring potential implementers off, and I believe we should offer an option where the requirement for two-way communication is avoided.
We could leave this undefined by the standard, but that would lead to many different custom mechanisms being implemented for uploading files, and it would be up to the callers to find out which methods are supported by each implementation before they could be used.
That’s my 2 cent.
Reynolds, Peter [mailto:Peter.Reynolds@bowneglobal.ie]
I am in favour of being able to use SOAP attachments for the Web service. I recognise the reasons which Stephen has mentioned in favour of URIs as being very valid but I think there are a couple of reasons why we should do both or SOAP attachments. The ideal from my perspective would be to do both.
With SOAP attachment we have a single call which submits the job or gets a quote and this also sends the file. With URI there may have to be an extra step where the file is placed at some address. This in my mind also lends itself to easier automation, but this might just be that the step of leaving a file to be accessed is eliminated.
There is a security issue in having a file somewhere on the Internet for collection. The FTP/ URI solution makes a lot of sense particularly with bigger files. However, our experience in using Web services at BGS is that the projects we were getting consisted of lots of small files rather than a small number of big ones.
The other argument I would like to make is that I feel customers would have more confidence in the SOAP attachment solution.
Peter Reynolds, Software Development Manager