views:

289

answers:

2

For a project I have to implement a communication between a database hosted on a web server and several clients out there in the internet. After reading a bit and watching a few introductory videos about possible (Microsoft) technologies I figured out that I seem to have (at least) three options:

1) Windows Communication Foundation (WCF)
2) ASP.NET Web services
3) ADO.NET Data services

Because I am not familiar with any of those three technologies I have to learn (hopefully only) one of them in depth - and the question is: Which one?

Or to be more precise: Which one for the following task?

Data need to be uploaded from a client to the server/database and some other data need to be downloaded as well. On client side this will not happen interactively by an user who works in a browser but rather as an automatic process on the client which will run periodicly (every 2 hours for instance).

a) On web server side there will be:

  • A SQL Server database
  • .NET Framework 3.5 SP1
  • A class library representing the database structure and modeled with ADO.NET Entity Framework
  • (An ASP.NET web application which will present the data in the database in a browser: I put this in brackets here because this web application doesn't really matter since the mentioned data up/download won't be triggered through a browser GUI.)

b) The client side is less clear and must be more flexible. Here I have to distinguish between two requirements:

i) Priority One (in terms of the time I have available for development):

  • The client side is under my control, it means: I have any Windows OS on the client, I can install .NET Framework and I can decide to develop a Windows service, a Console Application, a Windows Forms application or whatever. And I have knowledge about and access to the class library mentioned above.

ii) Lower Priority, but must be a future option:

  • I need to expose any kind of interface description which allows other developers to build their own applications to upload/download data.
  • The clients which others will develop for can be operated with any kind of OS (Windows, UNIX, MacOS and more). Also they shall be as free as possible to select their own prefered programming language.

Due to the last point forcing developers to use the .NET Framework on client side is not an option. The communication on client side must be any kind of "standard" technology accessible from various platforms and languages. I was reading terms like "SOAP", "REST" or "AtomPub" during my little research and these seem to be a kind of standard protocol or communication technology (not a proprietary Microsoft invention). But I am not sure nor do I know which technology is "up to date", has the "best future", is most common and well known, is the most powerful or is the easiest to use (from a viewpoint of those other possible developers! So the question is what I have to support to make most client side developers happy).

One last point: Security is important! Uploading/Downloading data must be restricted to dedicated persons. It should not be possible to use or explore the interface without appropriate credentials.

What technology is the best to use now? (1), (2) or (3)? And why would you recommend it?

Thank you very much in advance for any advice!

+7  A: 

Well, no. (2) old-style ASP.NET webservices is on its way out - it's old, no longer being developed - it's been replaced by WCF.

So this leaves options 1 (straight WCF) and 3 (ADO.NET Data Services - renamed WCF Data Services recently).

Both use WCF as their basic technology - so learning and knowing about WCF is a must in both cases.

With straight WCF (Option 1) you have more options - you can self-host, host your service in IIS, use different protocols and bindings and so on. But with choice comes complexity - you need to learn and know all that stuff - at least to some degree. Your client needs to be able to talk SOAP to you - just about any language (.NET of course, Java, Ruby, PHP - you name it) can talk SOAP in one way or another.

If you're mostly interested in exposing data from databases onto outside clients, I think WCF Data Services is indeed quite a good choice. It's based on REST, so you can hit your WCF Data Service with a browser and just see what happens. It's quite powerful, and even offer a LINQ client side support - you formulate a LINQ query and this gets translated into your appropriate REST call to your data service.

With WCF Data Services, your client needs nothing but a HTTP stack - even the iPhone has that :-) But with a .NET client, things are of course nicer and more comfortable and more efficient.

I'd say check out the WCF Data Service first and see if that satisfies your needs - and if not, dig deeper into WCF. Also check out WCF Data Service at a glance for an intro.

UPDATE:

Marc, do I understand you correctly that WCF on the server fulfils this requirement? And ADO.NET (WCF) Data services too?

Absolutely. WCF (plain or with Data Services) on the server side does NOT dictate the client in any way, shape or form. You can hook up an iPhone to a WCF Data Service, if you really feel like it :-) WCF has been designed from the ground up to be very interoperable - actually, it's the one platform out there that implements the most WS-* industry standards for cross-platform communications.

marc_s
"Well, no. (2) old-style ASP.NET webservices is on its way out - it's old, no longer being developed - it's been replaced by WCF."How does the cool-aid taste over there, marc? lol. And you may want to review the stated requirements.
Sky Sanders
+1 because I am a dork.
Sky Sanders
Interesting, I didn't know you could actually write Linq against Data Services. Can it do joins, subqueries, etc., or is it basically limited to what you'd expect from a REST service, simple queries against one type of object?
Aaronaught
Sure, the context is IQueryable. It constructs the REST uri. There are some limitations but more or less, yes.
Sky Sanders
A: 

ok.. UNCLE!!! i my answer was hasty, my comments a bit arrogant. And while seeming uninformed and ignorant, let me say..

DOH! I knew that.... ;-)

Sorry guys.

Sky Sanders
@Sky: you seem to be conflating ASMX web services (ASP.NET Web Services) with SOAP. WCF is a complete replacement for ASMX Web Services, which are "dead" in the sense that they're in maintenance mode, and only the most serious bugs are being fixed. There are very, very few reasons to do any new web service development using ASMX.
John Saunders
Well, perhaps I didn't make it clear enough: The question is what I shall use ON SERVER SIDE? I cannot use a technology on server side which FORCES to use the .NET framework in client side. If it is POSSIBLE to use .NET on client side, that's fine and will help me for task (b)i) (and other developers who perfer to use .NET on client side). But if I CANNOT use anything other than .NET on client side my decision for the technology on server side was a bad choice.Marc, do I understand you correctly that WCF on the server fulfils this requirement? And ADO.NET (WCF) Data services too?
Slauma
@Sky: see http://johnwsaundersiii.spaces.live.com/blog/cns!600A2BE4A82EA0A6!860.entry
John Saunders
@Slauma: WCF does not dictate the client side at all. You can use standard SOAP 1.1 or 1.2, WS-Security, etc.
John Saunders
@John and Marc: OK, I understand: WCF is fine, others can use SOAP (and REST as well according to another statement here) to communicate with the service. What about "WCF Data services"? Is it a "subset" of WCF which restricts communication to REST (so SOAP is not possible)??? And how to compare SOAP and REST? What is more common on different platforms? What is the majority of developers familar with and what is better supported?
Slauma
@Slauma: WCF Data Services is a layer of nice features **on top of** WCF - it uses WCF under the covers, but gives you a nice, easy to use REST-based interface. It just basically saves you from writing a lot of WCF code yourself - if it works for you, most definitely use it!
marc_s
@Marc: Sounds good, I would love to use the most comfortable and easy way for MY development. BUT: What about the developer of the client side interface who works with C++ on Windows without .NET, or with Java, with the developer on a AS/400 system, or someone who works with ABAPs in SAP, or whatever? It must not happen that if I offer them an interface based on REST they tell me "Hey, REST is useless for us, our systems don't support it and there are no libraries to support REST on our systems. Why do you use such an exotic technology?" So how widespread is REST on different systems?
Slauma
@Slauma: for integration, use SOAP. SOAP will allow these other platforms to read a WSDL file that describes your service. They will be able to use that description to decide programmaticly how to interact with your service. REST requires a programmer to write or customize a program.
John Saunders
Hopefully one last question to make sure if I understand that correctly. Marc said that WCF Data Services is build "on top" of plain WCF. Does this mean: If I have a service on server side developed using WCF Data Services then the client is free to use either REST or SOAP to communicate with the service?
Slauma
@slauma: no - WCF Data Services is **REST** - REST only. But to use REST, your client needs **only** an HTTP stack - that's all they need! Show me one platform today that doesn't have an HTTP stack..... REST is about as universal as it gets.
marc_s
OK, thanks to all for your help! I think I'll start to dive deeper into WCF Data Services.
Slauma