[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [trans-ws] Attachments v URI
|
Hi all, 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. Cheers, Magnus From:
Reynolds, Peter [mailto:Peter.Reynolds@bowneglobal.ie] Hi all, 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. Thanks, Peter. Peter Reynolds, Software Development Manager |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]