Up to this point, our application has been using Windows File Sharing to
transfer files to and from our application document repository. This
approach does not lend itself toward a secure environment and so we are in
the process of imposing a WebService gateway between our application client
and the repository.

(As a starting point, the WebService won't be a richly featured application
server; business rules are still implemented in the client. But this will
ensure that all access to the document repository is made via our software.
Although the WebMethod below accepts only a single parameter, I'll shortly
be adding authentication parameters to this method to ensure that accesses
to this WebMethod actually originate from our client application.)

Here is the method which I've defined (below). I have two questions, one
which relates to functionality, and the other which relates to performance.

1. I can't get this to work! When I test this I get the following error
message:

Could not open C:\Winzip.log --> Access to the path
"C:\Winzip.log" is denied.

Here's the line of code on which the exception occurs:

FileStream FS = new FileStream(FileSpec, FileMode.Open);

I can't imagine that this is a Windows security problem. I have anonymous
access disabled, integrated Windows authentication enabled, so the request
must be running using my credentials and I'm able to open this file via the
Windows shell. I imagine that perhaps I need to tweak a setting somewhere,
but I'm not sure where.

2. Is this the quickest way to stream a file back to a remote client? Speedy
delivery of the document to the client is critical and so anything that I
can do to improve performance is important to me. Maybe conversion to
Base64String is not as efficient? If I can use a more efficient format I
will. Just bear in mind that I need to stream binary files (e.g. JPG) as
well as textual, so I need a format which will preserve every bit as it
travels via HTTP.

Thanks very much for your advice!

- Joe Geretz -

[WebMethod]
public string GetFileStream(string FileSpec)
{
try
{
FileStream FS = new FileStream(FileSpec, FileMode.Open);
byte[] FileBytes = new byte[FS.Length];
FS.Read(FileBytes, 0, (int)FS.Length);
FS.Close();
return System.Convert.ToBase64String(FileBytes, 0, FileBytes.Length);
}
catch (Exception e)
{
throw new Exception("Could not open " + FileSpec, e);
}
}

Joseph Geretz wrote:
For transferring a file via SOAP take a look at the Microsoft WSE and
the SOAP Attachments specification it implements.

Cheers
Jimbo.

"Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote

Is this file on the Client's filesystem or the Server's?

Why don't you just use Windows SharePoint Services. It's part of the OS,
and that's what it's for.

David

Hi David,

Thanks for your response.

The file is on the server. That's the whole point, we're imposing the
WebService as a gateway between the server-side file repository and the
clients.

I am able to get access, by placing the following directive inside the
Web.config file:

<identity impersonate="true" userName="SRS\Joseph" password="foobar"/>

However, the following directive doesn't work, even though I am logged in as
SRS\Joseph.

<identity impersonate="true" userName="" password=""/>

I'm curious as to why the latter doesn't work. My site is set up to use
integrated Windows authentication. Shouldn't the transaction be using the
credentials SRS\Joseph in the latter case, just as it is in the former case?

Sharepoint stores its files inside SQL Server. BLOB access is not as quick
as native filesystem access. If we wanted to go that route, we'd have been
storing our documents inside SQL Server a long time ago.

Thanks,

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted meat (AT) hotmail (DOT) com> wrote in
message news:%23qIZoJZrFHA.1984 (AT) tk2msftngp13 (DOT) phx.gbl...

Cancel that. It does work.

- Joe Geretz -

"Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote

"Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote

Transfering over SOAP will require Base64 encoding and lots of memory on the
server, as you've discovered. Which is a far cry from native filesystem
access.

David

Yes. Our situation is such that we need to support two file access types.

Native Filesystem Access (Best Performance / Worst Security)
Via Web Gateway (Worst Performance / Best Security)

We're looking for a 'common denominator' repository so that clients can
easily transition from one approach to the other, or even support a mixed
approach, with workstations on the intranet using native filesystem access
and remote workstations using the Web Gateway access. Filesystem seems to
meet this criteria for us.

We've been doing filesystem access for years, so no issues there. Serving
these files up via HTTP will be a new option.

Is this an absolute given? Is there no way to transfer via HTTP using a
binary protocol? Should I be using Web Services at all for this? Maybe I
should be using Remoting? Jimbo mentioned a protocol called DIME which is
used to send attachments via Web Services. Maybe this is the best way to go?

Has anyone had experience with this; specifically the transport of binary
data via HTTP?

Thanks for your advice,

Joseph Geretz

"David Browne" <davidbaxterbrowne no potted meat (AT) hotmail (DOT) com> wrote in
message news:uxq0QiZrFHA.3852 (AT) TK2MSFTNGP15 (DOT) phx.gbl...

And one more follow up question:

So if I download a PDF from the web, or stream an audio / video file over
the web it always travels in Base64 format? Is there a more compact way in
which this can be transmitted in binary format?

Thanks,

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted meat (AT) hotmail (DOT) com> wrote in
message news:uxq0QiZrFHA.3852 (AT) TK2MSFTNGP15 (DOT) phx.gbl...

"Joseph Geretz" <jgeretz (AT) nospam (DOT) com> wrote

Yes. HTTP is a binary protocol, ASMX web service use SOAP and are XML
(text) over HTTP.

It's quite easy to send/recieve binary files directly over HTTP.
In ASP.NET you can access the request/response stream objects and write
bytes to the wire directly.
http://www.codeproject.com/aspnet/fileupload.asp
http://www.ondotnet.com/pub/a/dotnet...04/01/asp.html
http://www.15seconds.com/issue/010504.htm

You can also send binary files using web services, but you need an enhanced
web services implementation on client and server like Microsoft Web Services
Enhancements 2.0
http://msdn.microsoft.com/webservice...e/default.aspx

Which impmenents Direct Internet Message Encapsulation DIME for attaching
binary messages to web services.
http://msdn.microsoft.com/library/de...ml/wsedime.asp


David

Thanks for your help, David. We sure have a lot more choices these days. I
want to be sure I get this right.

Given the choice between classic ASP (i.e. using Request, Response, etc. to
communicate between client and server) and using Web Srvices with DIME (WSE)
what would you recommend? Can you point out some pros and cons to either
approach?

I've done several web applications in the past so I'm familiar with the
ASP/IIS object model, and I'm currently researching Web Service Extensions /
DIME. I can engineer the client to interface with either of these server
side approaches. Is it six of one / half dozen of the other? Or do you see
any of these approaches as being superior to the other?

Any quick pointers from someone who's 'been there / done that' will be
extremely appreciated.

Thanks!

- Joe Geretz -

"David Browne" <davidbaxterbrowne no potted meat (AT) hotmail (DOT) com> wrote in
message news:OoNIX2arFHA.3792 (AT) TK2MSFTNGP10 (DOT) phx.gbl...