WebServices based file transfer - not efficient?

[Piotrekk]

Hi

I have theoretical problem. In my web service project there was a need
to implement file download/upload using WS. I have created UploadChunk
and DownloadChunk methods which transfer files in chunks - consecutive
web method calls. The problem is, that when i am testing this approach
it seems that the transfer time ( many file sizes ) takes twice long,
comparing to when the transfer is stream based using regular
HttpWebRequest/response.

I'd like to ask you, if this is good practice to use stream based
approach in web services? If so, how should they be implemented?

Kind Regards
PK

[Marc Gravell]

That should be fine - however! Are you using MTOM? Both WSE3 and WCF
(basicHttpBinding) support MTOM; otherwise the data has to be base-64
encoded, which adds 1/3 to the size. WCF can also only do full
streaming if using transport security (message security requires the
full message before it can verify) - there is a streaming mode for
this.

Marc

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Piotrekk wrote:

I have theoretical problem. In my web service project there was a need
to implement file download/upload using WS. I have created UploadChunk
and DownloadChunk methods which transfer files in chunks - consecutive
web method calls. The problem is, that when i am testing this approach
it seems that the transfer time ( many file sizes ) takes twice long,
comparing to when the transfer is stream based using regular
HttpWebRequest/response.

I'd like to ask you, if this is good practice to use stream based
approach in web services? If so, how should they be implemented?

I think it is a bad idea to use web services for file download/upload
no matter how.

Web services are for passing method calls (RPC style) or structured
information (document style).

A file is just byte[] data.

Or to put it another way: the web service does not provide any
functionality not present in standard HTTP.

So use plain HTTP (standard ASP.NET upload or download script).

It is just as portable as a web service call. Actually more.

Arne

[Piotrekk]

I am not using MTOM - i have never tried that. I think that I'll try
to use streaming for transfers.
Thank you guys.

PK

[Marc Gravell]

Arne - everything you say is true; and this remains valid as long as
the web-service is simple; however, if you need to use a consistent
approach (security, logging, exception-handling, etc), then using the
same web-service to handle binary *is* a valid choice, as long as it
is handled correctly (chunking, and using MTOM). Additionally, the
fact remains that WCF can be used to provide a DI/IoC architecture
(useful for mocking etc), so can be a useful approach - and MTOM
minimised the overhead.

Marc

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Marc Gravell wrote:

Arne - everything you say is true; and this remains valid as long as
the web-service is simple; however, if you need to use a consistent
approach (security, logging, exception-handling, etc), then using the
same web-service to handle binary *is* a valid choice, as long as it
is handled correctly (chunking, and using MTOM). Additionally, the
fact remains that WCF can be used to provide a DI/IoC architecture
(useful for mocking etc), so can be a useful approach - and MTOM
minimised the overhead.

A normal HTTP download/upload script can certainly implement
security, logging, exception-handling, etc..

I know there are cases where BLOB's in web services make
sense.

But I still believe that for the specific purpose of file
download/upload, then plain HTTP is sufficient.

I must admit that I know too little about WCF to
comment on its DI capabilities. I do know that WCF
supports pure binary protocols.

Arne

[Marc Gravell]

A normal HTTP download/upload script can certainly implement

security, logging, exception-handling, etc..

Yes; I meant where it has to implement the *same* security; for
example claims-based on cardspace (or whatever).

Re DI - simply that WCF is interface based (rather than pure proxy-
based), which makes it easy to implement a factory / DI approach.

Marc