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!
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.
Related
What is the difference between WCF Services and Web Services in .netWhen should I use WCF and when to use Web Services.Is REST and WCF service the same? Thanks
Web Service is an abstract term encompassing a large variety of data providers for distributed systems. Perhaps you are referring to ASMX web services, which can still be found in the wild but aren't really widely used in new development these days.
WCF Service is Microsoft's implementation of SOAP. There are others implementations or you could roll your own (not recommended).
SOAP is a kind of stateful, session-based, message-based web service. It's good if your service is designed as a set of complex actions.
REST is a stateless, sessionless, resource-based web service. It's good if your service is designed to access data and perform simple CRUD operations on it. SOAP and REST are mutually exclusive. A service cannot be both. There are ways to manipulate vanilla WCF to make is RESTful but these techniques are becoming deprecated. If you want to implement a RESTful web service there are two main choices in the Microsoft world: WCF Data Services and ASP.NET Web API.
REST is an architecture
WCF is a API in .NET Framework to build connected service oriented application.
In olden days a functionality developed as Web Service was accessible via internet and the same to be available on local network was available via Remoting.
Using WCF we don't need to develop different code for it to be accessible over internet and on local network. Just configuring it with bindings would be enough.
That is a very wide question...I am going to just give a brief high-level answer and suggest that you do some more searching as there are is already a lot written on each subject. But, hopefully this should give you a push in the right direction.
First, typically when people refer to WCF Services and Web Services, they are referring to the newer WCF conventions that make service calls fairly generic (they can be SOAP, REST, etc) and the old .asmx SOAP method of Web Services. So, along these lines, I would suggest looking more into WCF and SOAP/.ASMX for the difference of WCF and older Web Services.
As to WCF and REST, they are not the same. REST is more of an architecture, whereas WCF is a framework. As I already mentioned, WCF can be used to make SOAP calls or REST calls. I am not sure I can add much more without going into greater detail.
I will see if I can find some good articles on REST and WCF a little later, though. Personally, I do not see a reason to even pursue very far into the older way of calling web services (.ASMX pages) as WCF has pretty much made that obsolete. However, learning many different ways to skin a cat can be useful in an endeavor to find what fits you best.
Again, this is VERY high level, but these are very general topics with a lot surrounding each, so hopefully a high level overview will help direct you in studying deeper on each subject.
Some people mean "ASMX" when they say "Web Services".
Others just use "Web Services" to mean the generic technology, and consider WCF to be the current way to create Web Services on the .NET platform. The other kind are "ASMX Web Services", as distinguished from "WCF Web Services".
The "other kind" are a legacy technology, supported only for backwards compatibility. They should not be used for new development, so there's no point in you learning about them.
As others have stated, "REST" is an architecture style, not a technology.
WCF is multifaceted, so I'm going to speak of it with respect to its most common usage. The general difference between WCF and REST services is centered around the content. A REST call is usually more message/document/entity centered (With customer entities, find those starting with M; With order entities, get order 12 and is tied to the HTTP protocol. WCF tends to be more operation centered (Invoke find operation with params, Invoke get operation with parameters). WCF also isn't tied to HTTP.
FYI, there are extensions to create REST based services using WCF (WebInvoke, WebGet attributes).
Wcf:wcf is a technology as part of .net framework which provides environment to work with different distributed technologies an by following unified programming model.
wcf create a proxy.
wcf support data contract serializer.
records shown xml format.
**Rest:**Rest is an architectural style.which says use the existing features of the web in more effective,efficiency and simple manner.verbs like insert,update and delete.
Rest cannot create a proxy.
rest records shown jason format.
Web Service:a service which is hosted on website is called as webservice.
web service support xmlserializer
I see this is quite an old thread, but I have asked a similar question recently.
The answers given have all similar relevance, but in my opinion Ray was the closest to what was actually asked.
When designing or refactoring a web based solution, you always get the question should we go with SOAP or REST. The answer lies in the complexity of the business logic required behind the service. REST is good for simplistic API calls that usually contains small sets of requested data or over night processing with large sets, but mainly for data requests. SOAP is more of an interactive day to day service with business logic as well. For example many methods with plenty of parameters.
What we do as part of our web based solution, is to try and make use of both. For internal methods and primary functionalities we use SOAP, but for exposed APIs we prefer REST.
Framework related, definitely WCF as preferred choice, irrespective if SOAP or REST.
I'm working on adding a WCF services layer to my existing .NET application. This layer will be hosted in IIS and will be consumed by a variety of UIs, at least one of which will not use Microsoft technologies.
I can make a Web service in WCF that is consumed by my .NET application. However, I'm concerned about things that work in the .NET world but not with other technologies.
For example, simply throwing an exception from my WCF service works fine in .NET. But according to this article, one should approach exception handling with fault contracts to ensure compatibility with non-.NET consumers. The author labels this lack of foresight as The Fallacy of the .NET-Only World.
Does anyone have any high level suggestions or links to articles that cover interoperability between WCF and non-.NET consumers?
I realize I'm potentially working against the YAGNI principle. I'm only really looking to avoid things that will be incredibly difficult to overcome later when the developers of the non-.NET consumer report problems to me.
use any of the WCF bindings that don't start with net - avoid netTcp, netMsmq etc. - those are .NET only
make sure to make good use of DataContract/DataMember attributes, so that your method input and return parameters are easily and nicely serialized
avoid any .NET specific types in your data contracts - don't pass back an Exception or something like that - use the SOAP (or REST) elements for those things instead
don't use things like DataSet, DataTable etc. - they're all heavily tied to .NET
make sure to properly catch all errors on your service side - e.g. by implementing IErrorHandler - and pass back SOAP faults instead (if you're using a SOAP binding) or a HTTP error code (for REST)
TEST your services with non-.NET clients! Run a PHP page against them, code up something in Ruby - whatever - test it and make sure it works
One good way is to make your services RESTful.
From Wikipedia - Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web.
REST style web services leverage the existing capabilities of HTTP to expose the services. Since almost every technology of building software can deal with HTTP you can be sure that your web services can be consumed by any non-DotNet consumer.
A very good example of RESTful services would be the stackOverflow API.
Here are some good links you can start with -
http://www.oracle.com/technetwork/articles/javase/index-137171.html
http://msdn.microsoft.com/en-us/magazine/dd315413.aspx
I'm pretty much a novice as far as WCF goes and I'm trying to figure out which type of WCF project to create for use by my windows phone 7 application.
There seems to be :
WCF Service
Silverlight-enabled WCF Service
WCF Data Service
As far as I can tell - #1 is an older variant, requires more configuration and an interface. #2 has some switches turned on that are required by Silverlight. #3 Talks to an entity model.
I am using an entity model so #3 looks good, but the examples I have seen look like it exposes the whole entity model. I want to pick and choose what tables to expose, plus create my own service methods using linq to join tables. Can #3 do this?
#2 looks better than #1 as it does not seem to require an interface and seems to have less configuration.
#1 looks most configurable which is both a good and bad thing. I guess this is my fallback position.
Any advice?
Cheers
Steve
What you're running into relates to the fundamentals of Silverlight (at least as it stands today.) Your conclusion is correct - the "Silverlight-enabled WCF Service" is probably your best bet for a quick service to call from the Phone app, but I'd like to offer a different take on the rationale.
Silverlight only supports a subset of the communication options offered by WCF - it only allows BasicHttpBinding, whereas WCF offers a whole lot more, including support for "enhancements" that are part of the WS-* specifications. As a result, you need to set certain flags and make certain choices in your WCF services in order to make them consumable by Silverlight. By using the "Silverlight Enabled WCF Service" template, that work is done for you. This also means that if you want secure web-service communication with Silverlight, you have to use/set up HTTPS.
As to the interfaces, etc., actually that works across both options - the need for setting up the ServiceContract vs "implying" it from the defined operations came around .Net 3.5 SP1, if my memory serves me correctly. Note that while "regular" Silverlight also has support for communicating with TCP-based WCF Services, I believe the phone does not.
Now for choice #3 - the WCF Data Service (or the artist formerly known as ADO.Net Data Services.) What this does for you is sets up a REST-based service to expose your backend data (where the previous 2 options are more/usually SOAP-based.) More details and introductory information on this can be found here - http://msdn.microsoft.com/en-us/data/bb931106.aspx. Now these services typically leverage plain old http, and are definitely consumable by Silverlight and the phone; also their payloads are lighter weight than the SOAP counterparts.
Whether or not to use REST or SOAP is a design choice - the SOAP approach is more RPC-like (define methods in the service that get called to perform specific actions with specific priorities), the REST option is more OOP-like, with some "auto-magic" thrown in for good measure. The thing about "auto-magic" is that you really do need to understand the magic (and its limitations) before you start, or your design could likely fail to meet your requirements.
Hope that helped!
John
There a lot of different ways a Silverlight application can connect back to it’ server. Including
WCF - Windows Communication Foundation
REST (see also)
ADO.NET Data Services (or is this just REST?)
POX - Plain Old XML (E.g basic xml)
RIA services
For each of these please say what it’s for and when you would or wouldn’t use it. I am not looking for a great level of details just a set of “rules of thumb” for choosing between them.
(The problem is when designing your first Silverlight application knowing what to use when you don’t have time to learn all of them.)
If I was to replace Silverlight with WPF in this question what effect would it have on your answers? (I am assuming with WPF that due to firewalls and admin policies a direct connect to the database is not an option.)
My two (euro) cents:
WCF seems best suited when the service can be viewed as the business layer of the application, that is, when your service has "intelligent" operations like "CalculateDiscountForClient".
ADO.NET Data Services (indeed, just a REST implementation) seems appropriate when your application is basically data-centric and the service is simply a front-end for the database. That is, all your service methods are of type GetCustomers, CreateInvoice, etc.
RIA services is a very new technology that I haven't experimented with yet, but it seems to be useful to create applications in which the Silverlight part and the service are very tightly coupled: you define your service classes and methods in the service project, and they are automatically replicated to the Silverlight project in design time. Also, you can define both WCF-style "action" methods and ADO.NET Data Services-style "data" methods. Looks promising.
Use POX if there is a chance that you change the client part from Silverlight to any other technology (for example HTML+AJAX) in the future, since it is the most interoperable option.
About differences for WPF, the only I can think of, is that for data access, whenever possible I would use direct ADO.NET data connections (properly embedded in a data access layer, LINQ to SQL or the like) instead of ADO.NET Data Services, since it is way more flexible. I must say anyway that I have never developed anything in WPF.
We use RIA, and that's the only one of the options that I know, but I do know it, so here's some of my thoughts.
RIA isn't finished yet. It is being worked on. If you are planning to be finished soon, and you're worried about having to support something that has a potential to change quite a bit, then you might want to consider other options. If this is a new project, and you're going to be supporting it for a long time, RIA will probably get easier to use.
Having said that, I kind of think that there won't be many changes in the way the July Preview of RIA works and the way that a finished version will work. Also the level of support seems to suggest that this will become "The Way" to talk to a server in Silverlight.
Just cause it's worth mentioning, have some links:
http://blogs.msdn.com/brada/ Brad Abrams has an example that he is continually updating.
http://forums.silverlight.net/forums/53.aspx this is where you go to ask questions.
http://www.riaservicesblog.com/Blog/ Colin Blair knows his stuff, and he is very helpful.
I think I would not go POX ever again. If you write WCF so that the service itself is independent of the binding and binding is done in configuration files, then WCF is pretty much agnostic about transport and protocol. It can do SOAP, JSON, REST, or its own form of binary serialization. All of this is in the binding. Internally, WCF only specifies what gets exposed in terms of operation and data contracts (all defined by class, method, and property attributes). WCF gives you tremendous flexibility in this regard, with more to come in 2010.
From the Silverlight side, WCF requires that you write some plumbing code. The .NET frameowrk has the tools to build the proxy in your Silverlight project, but you must be prepared to handle all WCF responses asynchronously, and the proxy cannot catch exceptions thrown by the service.
.NET RIA Services hides all this. It uses WCF under the covers, but that is completely hidden. You don't have to write asynchronous code. You define validation once, mostly declaratively, and it works both server-side and client-side. Release 1 will be targeted for Silverlight, so you don't get the versatility to use the service elsewhere. That scope is supposed to be broadened in later releases.
I don't know enough about ADO.NET Data Services to compare. I suspect the answer would depend on whether you want to expose your data to more than just Silverlight usage.
.NET RIA Services looks like the direction I'd want to go (looking at these issues myself, with a large application in mind). The big issues for me will be implementing a very large collection of functionality in the service layer, and not being able to code directly to the data access layer (we have to be able to run on either SQL Server or Oracle).
Using WPF instead of Silverlight changes everything, depending on where your data resides. It's like the old question of Winforms vs. ASP.NET. With WPF, you're building a Windows client app, and you don't need to use any form of service-based data interface at all, unless your data access forces you into it. You'll still want to separate data and business from presentation code, using MVVM, MVC, or MVP. Other than that, you have the option to treat data access as a layer, rather than a wholy independent tier.
WCF is Microsoft's standard for service communication. I would strongly advise anyone to create a service layer using WCF Web APIs (uses WCF, but tailored specifically for REST), which is coming out this April 2012. WCF Web APIs is currently in preview mode.
Remember these rules of thumb:
- your UI will change faster than your service layer. RESTful services will be around in several years, Silverlight probably won't
- will your services ever be APIs? Well...WCF REST is the way to go
- will you mix JavaScript and Silverlight code? WCF REST will make your life easier
- will you have a mobile component (since Silverlight won't run on iOS or android)...REST is preferred.
Don't tailor to the technology, but the app as a whole.
If you want to create a Silverlight Application and you do not care about other clients, then I would choose RIA Services. It is quite painless to use and you do not need to worry how the connection from the client is made (i.e. no client side configuration necessary). RIA also generates classes for all your entities on the client and you can even share your own "server" code with the client if required (useful for enumerations or extension methods).
Remarks:
I never tried this, but if you really need you can access the RIA Service also with other clients, after all RIA Services are built on top of WCF services.
I do not quite understand Akash Kava's security concerns. You can (and have to) control security on the server-side as you would do with any other service.
I am bit confused about ADO.Net Data Services.
Is it just meant for creating RESTful web services? I know WCF started in the SOAP world but now I hear it has good support for REST. Same goes for ADO.Net data services where you can make it work in an RPC model if you cannot look at everything from a resource oriented view.
At least from the demos I saw recently, it looks like ADO.Net Data Services is built on WCF stack on the server. Please correct me if I am wrong.
I am not intending to start a REST vs SOAP debate but I guess things are not that crystal clear anymore.
Any suggestions or guidelines on what to use where?
In my view ADO.Net data services is for creating restful services that are closely aligned with your domain model, that is the models themselves are published rather then say some form of DTO etc.
Using it for RPC style services seems like a bad fit, though unfortunately even some very basic features like being able to perform a filtered counts etc. aren't available which often means you'll end up using some RPC just to meet the requirements of your customers i.e. so you can display a paged grid etc.
WCF 3.5 pre-SP1 was a fairly weak RESTful platform, with SP1 things have improved in both Uri templates and with the availability of ATOMPub support, such that it's becoming more capable, but they don't really provide any elegant solution for supporting say JSON, XML, ATOM or even something more esoteric like payload like CSV simultaneously, short of having to make use of URL rewriting and different extension, method name munging etc. - rather then just selecting a serializer/deserializer based on the headers of the request.
With WCF it's still difficult to create services that work in a more a natural restful manor i.e. where resources include urls, and you can transition state by navigating through them - it's a little clunky - ADO.Net data services does this quite well with it's AtomPub support though.
My recommendation would be use web services where they're naturally are services and strong service boundaries being enforced, use ADO.Net Data services for rich web-style clients (websites, ajax, silverlight) where the composability of the url queries can save a lot of plumbing and your domain model is pretty basic... and roll your own REST layer (perhaps using an MVC framework as a starting point) if you need complete control over the information i.e. if you're publishing an API for other developers to consume on a social platform etc.
My 2ø worth!
Using WCF's rest binding is very valid when working with code that doesn't interact with a database at all. The HTTP verbs don't always have to go against a data provider.
Actually, there are options to filter and skip to get the page like feature among others.
See here: