Web Services Primer for a WinForms Developer?

Question

I've been writing client/server applications with Winforms for about six years now, but I have yet to venture into the web space (neither ASP.NET nor web services). Given the direction that the job market has been heading for some time and the fact that I have a basic curiosity, I'd like to get involved with writing web services, but I don't know where to start.

I've read about various options (XML/SOAP vs. JSON, REST vs...well, actually I don't know what it's called, etc.), but I'm not sure what sort of criteria are in play when making the determination to use one or the other. Obviously, I'd like to leverage the tools that I have (Visual Studio, the .NET framework, etc.) without hamstringing myself into only targeting a particular audience (i.e. writing the service in such a way as to make it difficult to consume from a Windows Mobile/Android/iPhone client, for example).

For the record, my plan--for now--is to use WCF for my web service development, but I'm open to using another .NET approach if that's advisable.

I realize that this question is pretty open-ended so it may get closed, but here are some things I'm wondering:

1. What are some things to consider when choosing the type of web service (REST, etc.) I intend to write? Is it possible (and, if so, feasible) to move from one approach to another?
2. Can web services be written in an event-driven way? As I said I'm a Winforms developer, so I'm used to objects raising events for me to react to. For instance, if I have two clients connected to my service, is there a way for me to "push" information to one of them as a result of an action by the other? If this is possible, is this advisable or am I just not thinking about it correctly?
3. What authentication mechanisms seem to work best for public-facing services? What about if I plan to have different types of OS'es and clients connecting to the service? Is there a generally accepted platform-agnostic approach?
4. In the line of authentication, is this something that I should be doing myself (authenticating an managing sessions, etc.) or is this something should be handled at the framework level and I just define exactly how it should work? If that's the case, how do I tell who the requester has authenticated themselves as?

I started writing an authentication mechanism (simple username/password combinations stored in the database and a corresponding session table with a GUID key) within my service and just requiring that key to be passed with every operation (other than logging in, of course), but I want to make sure that I'm not reinventing the wheel here. However, I also don't want to clutter up the server with a bunch of machine user accounts just to use Basic authentication. I'm also under the impression that Digest (and of course Windows) authentication requires a machine (or AD) user account.

Answer 1

1 -> REST is quicker than SOAP as (I think) it using HTTP nativly, but I don't think it is as secure. SOAP is more heavy weight, sending SOAP packets around header, payload etc.

2 -> Use can use asyncronous calls, but you can treat them like any other class, albeit without any state.

3 -> Due to the nature of our public facing services we have our own custom security webservice and pass a user cred object to every method to ensure the user is authenticated, and has permission. (this is a fairly simple solution, but a project all of it's own)

4 -> See 3. Though I am sure there must be some framework gubbins around for you to use. If everyone is on your domain, I'm pretty sure you can configure IIS to just authenticate those users.

Sorry this isn't a massibly detailed answer, like I said, you'd probably get better answers if you broke your question down into 4 parts.