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
Related
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.
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
I'm looking at creating a data query WCF service over a slow satellite connection and I really like WCF Data Services. The problem I see is that HTTP is a very verbose format and since everything I'm doing is internal and .NET, is it possible to use NetTcpBinding instead to reduce some of the overhead?
Is this even possible? Advisable?
While researching this on my own, i ran across the MSDN article on Self-Hosted WCF Data Services. This article notes that you can host the service with DataServiceHost which still requires HTTP (it's derived from WebServiceHost).
But you can also roll your own host using IDataServiceHost. Here's an excerpt from the MSDN article:
For cases where the WCF host
implementation is too restrictive, you
can also define a custom host for a
data service. Any class that
implements IDataServiceHost interface
can be used as the network host for a
data service. A custom host must
implement the IDataServiceHost
interface and be able to handle the
following basic responsibilities of
the data service host:
Provide the data service with the service root path.
Process request and response headers information to the appropriate
IDataServiceHost member implementation.
Handle exceptions raised by the data service.
Validate parameters in the query string.
The article seems to suggest that MS has properly segrated data-service responsibilities from network interface responsibilities. If that's so, then I should be able to write a NetTcpDataServiceHost. Has anyone ever written a IDataServerHost? Any suggestions?
No, WCF Data Services are built on top of REST, and REST itself is very intimately and completely based on the HTTP verbs like GET, PUT, POST etc. - you cannot run those over NetTcp, since those are intrinsically tied to the HTTP protocol stack.
Maybe there are other options for you to reduce the data being transmitted? Tweak your objects - trim the fat, if you can - both on the number of rows retrieved at once, and the number of attributes/data fields transmitted. That's probably you're most promising approach.
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.