We Keep Coding

Difference summary WCF and Web API

I'm looking for the difference summary between ASP.NET MVC Web API and WCF Service.
I've seen this question What is the difference between Asp.Net Web API and WCF Service?
and this question WCF vs ASP.NET Web API too, but they don't summarize what I can achieve with the one, what I cannot achieve with the other.
Both can be contacted via url, I first thought that was a difference between them.
So in short:
What can I do with WCF what I cannot do with ASP.NET Web API and visa versa?

this list is by no means exhaustive.
Things WCF does that you cannot do (with ease) using Web API.
Supports SOAP based XML format.
Supports strongly typed data contracts.
Supports a single point of metadata information exchange using WSDL etc.
Supports varied bindings like TCP, Named Pipes, MSMQ, even UDP etc.
Supports varied hosting options like console apps, WAS, IIS, Windows Services.
Supports one way messaging, duplex, message queues out of the box.
Supports multiple authentication schemes like Windows, Forms, Certificates etc.
Things Web API does that you cannot do (with ease) using WCF.
Supports the full features of HTTP. (Uri based access, Http Requests/Response, Http Caching etc.) To do this in WCF you need to additional work to configure it as REST service etc.
Is Lightweight with minimal configuration.
Supports the Routing, Controller/Action MVC paradigm, Model Binding etc.
Basically Web API is an easy way to do RESTful services over Http without knowing much about Web services.
To do the same in WCF, you need to do additional work in terms of httpBindings, UriTemplates, Verbs etc. And that means, understanding WCF first. And then using WCF to implement a RESTFul service over http, which is what Web Api provides out of the box.

This is not a summary per se. Its a sort of practical guide I hope.
For me it ultimately boils down to how simple I want my front-end application code to look like, and also something to do with how to achieve maximum productivity.
Traditional WCF over http is SOAP based messaging protocol. You add a service reference in your project, and Visual Studio takes care of generating the proxy classes. And you work with the instance of the proxy classes. So when you are writing your front-end code, you have intellisense to help you. Don't be fooled. This is just the IDE making life simpler for you. Underneath its pretty complicated. But my productivity is boosted to a degree. I don't have to write proxy classes. Hence, this is what I'd opt for a c# based front-end.
Alternatively, if I had to deal with a Webapi endpoint, I do not have the luxury of any IDE generated proxy classes. Therefore I'd have write code for everything. Typically I use the HttpClient classes to talk to my web api end points. Hypothetically, I could write a proxy classes to talk to web api. But it isn't as simple as in your wcf case where they were auto-generated for you.
On another line or reasoning, if my front-end was JavaScript, then my only best bet is have the web service hosted over web api, rather than wcf. If I were to talk to wcf endpoints from Js, that would be a PITN.
So it ultimately rests on your product plan, design, project schedules, etc software development plan. All the best.

Replace (Entity Framework Connection) to (WebServices) on Services Project

We have the following structure on our project in order to get data.
Acces to Database Using Entity Framework
ProjectName.DAL
Services that call Entity Framework.(UoW)
ProjectName.Service
Our Actions inside Controllers call Services and return data needed.
ProjectName.Web
The Question:
Our services take info directly with Entity Framework, What are the advantages and disadvantages about creating WebServices in order to replace the connection with EF? "In that case only WebServices will have access to Entity Framework,"
ProjectName.DAL
ProjectName.WebServices
ProjectName.Service
ProjectName.Web

The main advantage is that you would have a more decoupled design.
By exposing your DAL through web services you "disconnect" it from your frontend. For example, a mobile app, a web app and a WPF desktop app could all access your DAL through the same web services. So you can reuse your DAL accross different apps which can save you a lot of development time. Have a look at ServiceStack and advantages of its web services.
Disadvantages? Having to do some additional development work and testing. If your app is a simple and will not be used in different environments it may be overkill to use web services.

Disadvantages:
Web services tend to consume more resources from your server than just a plain CLR (aka dll) layer in your project.
whatever web service you plan to use (legacy web services, service stack, wcf, Web API, etc) you'll find that all of them have to use a process to serialize the data and it could be the case that you'll need to do the inverse process in your front end application.
you have to design your ws very carefully because you have to think how you're going to expose those services and the level of encapsulation/abstraction you will have to put in place, a bad design in a web service layer definetely will be a headache for you during development and production.
Security: In most cases you will have to validate every input in those web services as well
Advantages
well that's very relative to call an advantage, it depends more on what are your app requirements, some questions you need to answer are like the following:
Do I need to share data with other apps (mobile, desktop, other web
apps)?
Do I need to expose some functionalities to other business (third
parties)?
Recomendation
If you plan to do a CRUD application I'll recomend to go with REST definetely is the best option due to it's architecture (POST,DELETE,GET,ETC).
if you don't need you a web service right now, you can try to develop your service layer kind of like a service implementation in service stack but try to remain as POCO as possible and if for some reason you'll need a web service you can try to refector the service layer intead to have another level of indirection in the middle.
just my two cents...

How do I call a SOAP based Web Service from within a .asmx page?

I am trying to create a sort of "bootstrap" web service using a classic .net C# .asmx page and not WCF. (The business requirements for this project are specific and do not want a WCF service).
Basically, I am trying to do this:
Create a new web service (I have no problem doing this)
That service needs to make a SOAP based call to a Sharepoint Web Service
I need to consume that service
I need to add additional pieces of information for my web service to the SOAP result (No problem here either)
The issue I have having is with point #2 and #3. I have found plenty of articles using WCF to consume SOAP based Web Services or using "Linq" to connect to sharepoint etc., but that's not what I'm looking for.
What I am looking for is simply a step by step process of what I need to do to push me in the right direction.
Example:
add a web service reference??
add this line(s) of code to create a new SOAP request??
add this line(s) of code to parse and consume the service??
Thank you very much in advance!!!
Sample code would be greatly appreciated as well!

There's nothing magical about the fact that it's a web service. Just use "Add Service Reference" and then treat it like any other piece of code referencing a web service.
Also, are those who wrote the requirements aware that a WCF service can expose a basicHttpBinding endpoint that looks exactly like an ASMX web service endpoint? It would also have the benefit of all of the features of WCF, in addition to not using what Microsoft considers a "legacy technology".

The SharePoint Developer Center at MSDN would be a good place to refer to for general information, tutorials, etc. Server and Site Architecture: Object Model Overview in the Windows SharePoint Services 3 SDK would be a good place to start learning about the SharePoint object model, as the terms (SPSite, SPWeb, etc.) that you'll come across in examples can be confusing.
Basically you will want to add your web reference to the SharePoint web service that you intend to use. The specific reference that you use will depend on what you're trying to accomplish, there's a whole list of available Windows SharePoint Services Web Services. Those are for general SharePoint tasks such as interacting with lists and sites; there's also a whole separate set of web services for SharePoint Server which is what you would use for interacting with the Business Data Catalog, Enterprise Search, and any of the other features that come with SharePoint Server, not Windows SharePoint Services.
When you add the web reference in visual studio, it will automatically generate the proxy in your project against the remote web service and you use the generated proxy to do what you want to do. However, working directly against the web services, pretty much everything will return a generic XmlNode that you'll have to deal with, so if you're working in .NET, a much better alternative to using the web services directly would be to download the SharePoint SDK and program against the server object model.
If you do end up using the object model, make sure you read both of these thoroughly:
Best Practices: Common Coding Issues When Using the SharePoint Object Model
Best Practices: Using Disposable Windows SharePoint Services Objects

Here is small tutorial on what you're trying to do:
http://www.xefteri.com/articles/show.cfm?id=15

WCF database wrapper

I need to do a WCF service to wrap up the database access. I do not want the service to be bind to any specific database. In fact, it will only receives a query and returns a dataset. no treatement on the data will be done in the service so I want pure performance but it need to be secure too.
Actually, I think using perCall session, net.tcp binding and certificate autentification on both side. (it's a WAN app)
Still, can someone give some advices on the configuration that I should use?(Type of Session,Type of binding,Type of security,etc..)

It sounds like you could take advantage of WCF Data Services.
WCF Data Services (formerly known as
"ADO.NET Data Services") is a
component of the .NET Framework that
enables you to create services that
use the Open Data Protocol (OData) to
expose and consume data over the Web
or intranet by using the semantics of
representational state transfer
(REST). OData exposes data as
resources that are addressable by
URIs. Data is accessed and changed by
using standard HTTP verbs of GET, PUT,
POST, and DELETE. OData uses the
entity-relationship conventions of the
Entity Data Model to expose resources
as sets of entities that are related
by associations.

WCF Data Service - Proxy mid-tier service

The project we are working on is a classic 3 tiered architecture. tier 1 being the database server, tier 2 the application services and tier 3 the presentation tier (a web site).
In the application services tier I have a project that includes an entity framework model and a WCF data services based service that exposes the entities within the model e.g.:
public class DataService : DataService< PortalEntities >
This is a fully fledged OData service that can be queried through the URI e.g.: /dataservice.svc/mytable?$filter=contains(fieldname,’string’). This is great for the guys developing anything using jQuery as all they have to do is define the query. The problem is that this service is a mid-tier so it cannot be seen by the outside world.
The solution that I am trying is to expose another WCF data service on the web site that exposes the entities created by the service reference. If I add a service reference to the mid-tier service it gives me a data context that data context is being used in the new WCF Data service:
public class DataService : DataService< PortalEntities >
I do have to overwrite the CreateDataSource:
protected override PortalEntities CreateDataSource()
{
return new PortalEntities(GetMianModelServiceUri());
}
The new service does act like a proxy and does return the entities exposed (the query .../Services/OData/DataService.svc/tbl_Country works fine).
But when a query is passed to the service e.g.: .../OData/DataService.svc/tbl_Country?$select=Name it throws a not implemented exception.
Any ideas on how to extend the web site service so that it supports the same queries as the mid-tier service?

If you don't need to change the shape or functionality of the data server, you should be able to simply forward the requests and responses, just like a transparent HTTP proxy. The only difference you might need to do is to tweak the service URL. Since the proxy service will have a different base URI than the real service, the payload would contain the real service URIs (in the links and such), which would not work. You can workaround this by using a custom host for your real service and lie to it about its URI. This is done through IDataServiceHost2 interface, you return the "new" URI from the AbsoluteRquestUri and AbsoluteServiceUri properties. Nice sample of an implementation of the interface (although for a different purpose) is here: Link.
If you need to change the shape or functionality, then you really need a true layering.
Layering one WCF Data Service over another is currently rather hard. The LINQ expression trees generated by the "Server" are not always understood by the "Client" LINQ provider. That's what you're running into.
There's a prototype (more like an experiment) of making this work to some extent by rewriting the expression trees. It's part of the OData Provider Toolkit which you can download here http://www.odata.org/developers/odata-sdk#/media/7579/odataprovidertoolkit.zip. (It's in the Experimental folder, AstoriaOverAstoria project).
But please be aware that this is really just an experiment to show what kind of issues are there to be solved and so on. I definitely recommend to NOT use it in any kind of production environment.

I have found it possible to expose a service on the Web Tier that references a service (not data directly) on the App Tier. This only works for queries at the moment. I am not sure what is needed to get it working for updates, deletes etc. Any Ideas anyone? Anyway, here are some instructions and code snippets:
First you create a WCF Data Service on the App Tier bound to your edmx model.
Then create WCF Data Service on the Web Tier not bound to an edmx model (custom).
Create a Service Reference in the Web Tier Service to the App tier service.
Pass the Entities type to the DataService generic declaration (should be angle brackets for VB but I couldn't get them to show:
Public MyWebTierService
Inherits DataService[MyServiceReference.MyAppTierEntities]
Add an override for CreateDataSource() that creates your reference to the App Tier:
Protected Overrides Function CreateDataSource() As MyServiceReference.MyAppTierEntities
Dim ctx = New MyServiceReference.MyAppTierEntities(New Uri("http://yourappservicelocation/AppService.svc/"))
Return ctx
End Function
All you do now is create a reference to the service or bind it to your client app that
supports OData. JSONP support can be added if required.
So, this works fine for Queries but not for updates, probably because the Types are not the same (they may look the same, but are in difference assemblies after all). So, tracking is lost between the Web and App Tiers.
It may be that we have to implement IUpdatable on the Web Tier to solve this. Not sure yet so any input would be useful.
Hope this helps