I have an ASP.NET Web API 2.0 OData service project which I am trying to relay via a service reference + WCF Data Service (5.6) through an ASP.NET MVC project—the reason I am doing this is so users browsers’ can access the service without worrying about CORS for IE8 and IE9— so they will have the same host.
After some tinkering, this setup mostly works however there are some problems, my setup:
Service Project
1) ASP.NET Web API 2.0 OData endpoint
2) WCF Data Services 5.6 OData endpoint + Entity Framework 6.0.2 (EntityFrameworkDataService<DBContext>) using WCF Data Services Entity Framework Provider (1.0.0-alpha-2)
When I directly access both of these services they perform flawlessly with whatever I throw at them—both through a service reference, LINQPad, and raw URLs. Then I setup the ASP.NET MVC project:
ASP.NET MVC Project (relaying service references above): WCF Data Services 5.6, (DataService<ServiceReference-1-or-2>)
The problems come when I try to perform the same queries on the WCF Service acting as a relay:
Relaying (1) with $inlinecount=allpages gives me: “An error occurred while processing this request.”
Relaying (1) and (2) with $select=... both give me: “Not Implemented”.
When I relay a dummy POCO context through the reflection provider all of the operations work flawlessly on the relay WCF Data Service, which leads me to suspect that the problem is in the combination of WCF Data Services and the Service Reference, as they both work without problems independently… Perhaps the WCF Data Service is examining the LINQ Provider for the service reference and arbitrarily deciding that it does not support the operations?
I could live without $select but not having $inlinecount is a deal-breaker. There are a couple of alternate solutions I could take but I would really like to make this approach work: any ideas?
This was very similar to: WCF Data Service - Proxy mid-tier service
In a nutshell: you can have a relay by either
1) Making the service believe it is at a different URL than it is (so it is effectively broken for all access except through the proxy).
or
2) By writing another service which manually does the relaying to the service reference...
I chose none of the above and restructured my service as Web API Owin middleware. I lost the ability to have a separate service deployment but can easily swap in another piece of middlware and it makes CORS issues non-existent.
Related
Currently VS 2015 Update 2 provides an easy way to create owin based stateless web api service using create new service template for service fabric application. Is there a reason why only stateless web api service template is provided and not stateful web api service? If I wanted to, can I modify the stateless web api service to derive from stateful web service? Is it that simple? Or are there any gotchas with this approach?
Web Api is intended to be facade/public entry point to the service fabric app. Being stateless saves the clients from dealing with resolving partitions/addresses and other hassle.
If you want to - you can modify web api service and make it stateful. Maybe it would be even easier to create stateful service from the template, install missing packages (that web api template has), copy OwinCommunicationListener and Startup, wire them into CreateServiceReplicaListeners override, and add valid service endpoint to ServiceManifest.xml. OwinCommunicationListener will provide unique address for each replica.
Yup, you certainly can modify it to be stateful. Web API is great for internal service-to-service communication as well as a public-facing API.
There is a caveat that we are currently working through: The web host for stateless uses Kestrel, which presents some difficulties for stateful services where multiple replicas share the same process, because Kestrel doesn't have the same port-sharing capabilities that http.sys-based hosts do. We're working on a solution that makes it easier to use Kestrel for stateful, but in the meantime you can always use the WebListener host, which is the http.sys-based host.
If you're interested, I'm working on a project that will have an ASP.NET Core 1 stateful service (among other cool things) that you can track here: https://github.com/vturecek/service-fabric-xray.
We have some legacy OData service code in our application which is written using a WCF Data Service.
Everything else in our system now uses Web API as the data interface so I am wanting to port our WCF OData Service to a Web API service with the OData annotations.
My question is, we currently use the OData service for standard CRUD statements and also a lot of Service Operations. Are there any limitations with Web API OData that would limit it compared to WCF Data Services (i.e relationship chains, service operation calls, etc.)? I'm wanting to get away with updating the service so the client side of things doesn't have to change at all.
I've started working on a similar port from WCF to WebAPI for OData with the recent release of Web API 2 and its support for $select and $expand - until then I could not really replace the data service. Service operations can be added as actions
I am using AMX Service Bus 3.2. and trying to expose my rest services (ASP.NET WebApi) through the TIBCO Active Matrix. Unfortunately I have not found any way to do this in TIBCO business studio.
I found TIBCO Active Matrix Binding Type for REST but it is intended only for promoted services. It allows to expose SOAP services via REST interface but it is unable to invoke my REST services hosted on IIS.
As for now I see the only one way to implement that - Create addition SOAP service that will redirect HTTP request from Promoted service to my REST Service. But such solution is not very good SOA design.
Any help is appreciated.
I have been catching up with MVC4 Web API and WCF Data Service. From the surface, they both seem to be able to work with oData in the consuming client. I wonder which one is better for separation of concern (separate data service layer from UI layers). In my current solution, I have a plain MVC 3 style Intranet project and a MVC Data Service project. The 1st project has a Service Reference to the 2nd project. My goal is to write the data service once and make it available to all projects that would need to access underline database. When I read about Web API, it seems to me that the ApiControllers can return oData compliant result to the consuming client without MVC Data Service. My confusion is how I am going to expose this Web API MVC project as a service endpoint. Should I wrap it in WCF? Thanks.
You just create a controller inheriting ApiController and decorate one action with [Queryable] attribute, Rest depends on your route setup. Easy-Peasy.
Which one better? Web API. Since it has all the goodness of HTTP and you are not restricted to ATOM format.
You may use PocoHttp for seamless access of the data from your client.
I am really confused about when to use WCF and when to use ADO data services in my website ajax calls.
I always make my javascript code call a webservice to get data from server "ajax".
But while reading in both WCF and ADO data service, i am not sure when to use each and when not use?, and if they replace each other in my case? or can live side by side?
Can anyone make me understand in points when to use which in ajax websites?
ADO.net Data Services is a library to expose a datasource thru Wcf.
As such the functionality exposed by an Ado.net Data Service is for reading, updating, creating and deleting records in that DataSource.
With Wcf you can expose any kind of functionality (that's why an ADO.net Data Service is a WCF service)
So to answer your question, if your client application needs direct access to the datasource then Ado.net Data Services will provide that functionality out of the box.
If the client needs to talk to a Business Layer which in turn will access that Data Access Layer then you will expose that Business Layer as Wcf Services.
You could well use both approaches in the same application:
Exposing some tables directly using ADO.net Data Services
Exposing Business Logic with a WCF service
In a banking application for example you would not expose the Account table because you want to enforce some business rules.
In a simple ToDo list application you could expose the Tasks table using ADO.net data services because there is no business logic to be applied (note that I said SIMPLE ToDo list app)