Is it possible to use oData with a WCF service application but not use WCF Data Services?
It will be great if someone could shed more light on oData. I have done some Googling on this topic, but whenever I search for "wcf odata", I get information about WCF Data Services.
Any help/links will be appreciated.
WCF Data Services is the Microsoft implementation of the general OData protocol. As such, only WCF Data Services are / support / implement OData - a "normal" WCF service does not (and can not).
You might need to elaborate exactly why you feel the need or urge to use OData but not use WCF Data Services. What's the issue / problem you have with that setup? WHY do you want to use only a "normal" WCF service??
Update: ok, so you want to have services that expose data in different fashions and with different methods. What you could do is create a regular WCF service that's exposing both SOAP endpoints as well as a webHttpBinding REST endpoint. This will work - but then it's a "regular" WCF service, with methods that take parameters and return some data structure. This is not WCF Data Service (OData).
OData is more of a "here's my data collection, you can browse around in it" kind of approach - it's more about exposing an entire data model to the outside world using REST. This doesn't mix and match with SOAP - which is a lot more procedure-oriented, e.g. LoadCustomer, SaveInvoice and so forth.
So while it's absolutely possible to have procedure-oriented WCF services exposing both SOAP and REST endpoints at the same time, I don't really see how you can mix and match the "expose-this-resource" kind of approach for WCF Data Services / OData with a SOAP binding - this just doesn't work, I believe.
So if you must expose your data model of WCF Data Services (OData), you will need to author a second, pretty different looking regular WCF services for the SOAP clients, that might be based on the same data in the end (access the same database, for instance), but it's "face" will look quite different.
There is a new(ish) project from Microsoft called WCF WebApi (NuGet Package), which is simplifying doing RESTful WCF. It really takes to heart the "Representation" part of REST, so that you can expose your data in many representations (JSON, XML, oData, PNG, etc) based on content negotiation (or optionally whatever convention you want) all from the same service contract operation. Currently baked into the framework is the ability to support oData GET queries, by simply returning a collection .AsQueryable().
While this isn't a pure WCF/oData solution, as your question is speaking to, I thought I would mention the project in case it fit your specific requirements. The current Go-Live licensing might prove prohibitive, as might the "preview" status of this code; but if not, this may be a solution for you.
* UPDATE * This project was rolled into ASP.NET (usually in conjunction with ASP.NET MVC) and is no longer under the WCF team. The new product is called ASP.NET WebAPI.
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 looking to create an Application Object Server that is sitting between Window form client and SQL 2008R2 Database, it handling application business rule and support CRUD, I have achive this with WCF and WCF dataservice in the past, It would be better if we can combine those two kind of WCFs into one.
Do you know any way to achive this? or we should go back to the WinSock day.
Awaiting for your thoughts
WCF Data Services are based on the REST-style WCF services (webHttpBinding) - so those are quite fundamentally different from the traditional SOAP-style WCF bindings.
I don't see how you could easily combine WCF Data Services with a traditional SOAP WCF service (assuming that's what you're trying to do).
What you could do is:
create an entity data model as basis for both services
create the WCF Data Service on top of that EDM
separately create a set of WCF SOAP service methods, based on the same EDM
But SOAP and REST are quite different, at a very basic level:
REST tends to work with resources - you have a Customer (also in your URL), and you can fetch it, edit it, update it, delete it
SOAP on the other hand tends to work more with operations - you have your customer, but then you expose methods like GetCustomer, UpdateCustomer etc. - your basic building blocks are methods that take parameters
I have just started evaluating whether or not I should be using OData influenced wcf data services or a standard WCF service application as the primary data source for Silverlight applications. I would like your thoughts on which is a better way under what situation/circumstance. What is lighter over the wire, easier to maintain, etc.
What I have gathered so far is:
There are no Wcf data service templates in VS2010 that I know of, and I will need to create a asp.net web project first and then add a wcf data service, so its going to affect how I structure my projects.
WCF Data services expose actual table names over the service. I don't know yet of a way I can alias them and I'm not sure its a good idea to let the world know my table structure
In a standard wcf service I will need to write linq queries against the EF or Domain service classes on the service side, while in a data service I can move that processing logic to the client.
At first glance examining the classes exposed by the wcf data services seem easier to read and understand than those exposed by the EF
Do add your thoughts on this..
Thanks for your time.
There are no Wcf data service
templates in VS2010 that I know of,
Not project template - just an item template (for use inside an ASP.NET web site or web app). WCF DataServices are very tightly coupled to HTTP, so they only make sense in a web site/app.
WCF Data services expose actual table
names over the service.
NO ! At least not necessarily. The whole point of EF is that you can decouple the actual physical structure of your database from the (conceptual) model that gets exposed. You can totally rename entities, you can map several entities onto a single table, split up an entity over several tables, you can leave out attributes - anything you like!
At first glance examining the classes
exposed by the wcf data services seem
easier to read and understand than
those exposed by the EF
I doubt it - because by default, WCF Data Services will use a Linq-to-SQL or EF model as their basis, really. You can make that as simple or as complicated as you like.
Using a "regular" WCF service allows you to use the netTcpBinding for much faster performance (thanks to binary message encoding vs. textual messages for other bindings), when using your Silverlight 4 app in a company-internal network (doesn't work for internet scenarios) - not something you can do with WCF DataServices.
The main difference in my opinion is the SOAP vs. REST difference:
SOAP (traditional WCF) is oriented towards methods - you think and design your system in terms of methods - things you can do (GetCustomer, SaveOrder etc.)
REST (the WCF DataServices approach) is all about resources, e.g. you have your resources and collections of resources (e.g. Customers) and you expose those out to the world, with standard HTTP verbs (GET, POST, PUT, DELETE) instead of separate specific methods that you define
So both approaches have their pros and cons. I guess the most important question is: what kind of app are you creating, and what kind of user audience are you targetting?
Update:
for intranet / internal apps, I would think the advantage of a netTcpBinding (binary encoding) would justify using a classic WCF service - also for data-intensive apps, I personally find a method-based approach (GetCustomer, SaveCustomer) to be easier to use and understand
for a public-facing app, using HTTP and being as interoperable as possible is probably your major concern, so in that scenario, I'd probably favor the WCF Data Service - easy to use, easy to understand URLs for the user
Assume a situation where a data will never be queried directly. AKA, there will always be some filtering logic and/or business logic that must occur.
When is a good reason to use data services outside of ajax/js?
Please don't site this page http://msdn.microsoft.com/en-us/data/bb931106.aspx
Your essentially asking what layer of abstraction should I use, WCF Data Services is built on top of WCF and aims to simplify the process of creating a REST based service that is consumable by anything on the web. It takes away a lot of the plumbing and configuration required to do this with a standard WCF service. The querying feature is another big plus and something that is difficult to get right with standard WCF.
So in short:
If you want to quickly build a loosely typed service that wraps an existing data model and enables querying support give WCF Data Services a go.
If you want full control over the service contract or the flexibility of exposing the service over any protocol, stick with plain old WCF.
There is ASMX, WCF, REST, and ADO.NET Data Services... I've used WCF and ASMX succesfully with Silverlight 2, but what about the others? What are the pros and cons of using each type of service with Silverlight 2?
WCF is probably what you want, since it is a framework that includes http, soap, tcp, json, etc.
You have multitude of options -
RESTful webservice (if u need more than just CRUD) + ADO.net Data Service (Data)
The Tried and tested ASMX
Build an all in one WCF service that uses SOAP/HTTP/TCP/JSON/Your custome binding
Number 3 is my personal choice.
Depending on your intent a few things you must also take into consideration:
RESTful web services are supported by ADO.NET Data Services as well as many other non-Microsoft platforms.
WCF Web services must include a policy xml file and support more enhanced but Microsoft specific implementations of WS-* (WS "deathstar" if you want my opinion)
ASMX web services are simple but lack the security model built around WCF (either RESTful or SOAP based).
If you want to do fast prototyping, I would recommend using ASMX services since they involve the least amount of effort. If you are doing something that involves a lot of database interaction, consider using ADO.NET Data Services and a RESTful approach. If you would like to add a lot of complexity, but benefit from more robust security and configuration, utilize WCF.