views:

86

answers:

3

I need to produce a web service that looks to the client side like a file system. I will need the client to be a able to:

  • load files
  • save files
  • access meta data about files
  • use username/password

The reason I don't want to just host static content is that:

  • some of the content will be virtual.
  • some of the meta data will be non standard.
  • I will need to add custom hooks, access controls and error handling.
  • there are plans to do some processing/filtering of the on-the-wire data so I need to be able to add in custom code on both ends.

If it makes any difference, all the content is of the same type and will be deserialized/serialized on load/saves.

Is there a standard way of doing this? Is there a better way of doing this?


edit: I have bean playing around with Visual Web Developer and it allows remote calls (via SOAP, it think) give code like this:

public class HelloWorld : System.Web.Services.WebService
{
    [WebMethod]
    public string HelloWorldMethod(int x)
    {
        return "Hello World" + " " + (x * 2).ToString();
    }
}

That gets about 90% of what I want. the rest is having a single instance of that serve an entire subdirectory (and getting the path), getting IIS to handle all my security and a few other nuts and bolts.

A: 

It might be worth looking into the WebDav protocol there are extensions related to metadata. Not sure if this quite is what you mean by webservice, if you mean SOAP then you might follow the protocol but wrap it in SOAP.

danswain
WebDAV might work but we have some fairly specific version requirements. If implementing our own system is as simple as it looks like it should be (see my edit) than it wouldn't take much before trying to fit in there box gets to be more trouble than it's worth.
BCS
A: 

Have you considered implementing a protocol like WebDAV or even FTP? There are already file service and file transfer protocols designed. Even if you can't use a third-party implementation of one of these, you could at least implement the protocol and save yourself from reinventing that particular wheel.

If necessary, you could translate one of these protocols into a web services interface - but at least you'll have a full protocol to choose from in your design process.

John Saunders
+1  A: 

I would recommend checking out WCF instead of .NET webservices - it gives you more flexibility, more options, e.g. "reliable sessions" (which will deal with short network hiccups), and it gives you easy support for MTOM encoding for large messages, and even supports streaming, if you plan on serving up e.g. video or other content.

Marc

marc_s