I am starting development of the new project and since I am new in the WCF world I want to ask your advice.
I am going to implement web-service which will provide data for WPF client and for ASP.NET site. Web site and web service should be hosted in the Windows share hosting (not didicated server) and this fact is bothering me. WPF client and web site will provide almost the same functionality for the user, so I want to implement all logic inside web service not to duplicate it in the client and web site.
Not sure what is the best way to implement such web-service - REST, SOAP or something else? Please, help me with selecting technology for web-service creation, I just want to get direction for optimal solution. 10x.
Update: Sorry I did not wrote details. Service will be something like on-line shop with admin panel, so web service will be used for getting products and for adding new product to the system. It does not support tons of customers, it's just solution for small web-shops.
since you are developing a Web based solution and a WPF client, i would recommend the following options for your WCF services:
REST Option - This option is good if you have some complex Ajax architecture on the client using Json and stuff, or if you want to expose your services publicly. In this case the option is to expose an HTTP endpoint using webHttpBinding on your service. Since your deployment will be on a shared web server, you can host your service inside IIS. I would recommend considering a SSL option for security.
Soap Option - This options is the easy one, and should be more familiar to most developers, since it acts like a usual web service. In this case i would use an HTTP endpoint with wsHttpBinding on the service for enhanced security. Since your deployment will be on a shared web server, you can host your service inside IIS. I would recommend considering a SSL option for security.
Whatever solution you choose you will be able to accomplish your goal to have simple SOA architecture in place and will have centralized services for your CRUD operations.
I hope this answered your question.
Related
There is a requirement to have a common web api application to service 3 different MVC web applications. These client web applications have their own databases and own authentication implementations. How do we configure the web api application to provide access to a set of APIs to web app 1 alone and deny to all other web apps, similarly for web app 2 and so on? In other words, is there a way to 'register' each web app with the web api service and also build in a mechanism through which the web app is only allowed access to a set of endpoints? Thanks for all the help..
There are a handful of ways of solving this
Host multiple WebAPI servers in a single process to effectively meet your requirement while making your project easier to organize
Use Authentication and Authorization filters to customize how requests are accepted, denied, and routed
Using a router and/or switch at the hardware level, create a blacklist/whitelist combined with a reverse proxy (beware of MAC spoofing, etc, with this solution)
Use dependency injection to add abstraction to the process and to remove the ability to specify a custom endpoint in an unintended manner programmatically; this solution will only work if you control the client code, however
From the sound of it, the issue you're describing doesn't seem like one regarding the visibility of the endpoints, but of the access control to leverage them. If I'm wrong, please let me know in a comment and I'll update my answer.
Initially when I built an application, there was only a requirement to expose an endpoint using WCF. Now, there is a requirement to expose another endpoint using REST therefore I have used .Net Web Api to do so. The WCF endpoint is hosted in a Windows service therefore I have hosted the Web Api endpoint in the same service. Are there any issues in doing so? Any performance considerations? After some exhaustive searching, I couldn't find any substancial information on the topic.
Are there any issues in doing so?
It may be better to expose the rest API via WCF using webHttpBinding rather than introduce WebAPI into the mix. I'm not aware of any problems this would cause per se, but in terms of solution simplicity I think it makes more sense to take advantage of WCF's multiple-endpoints-to-one-service-contract mapping capability.
I did consider this but I've read a lot of bad reviews about using WCF
to expose RESTful endpoints. Moreover, it appears Web Api is the
preferred technology as mentioned here:
WCF vs ASP.NET Web API
Agreed. If you were starting from scratch then I wouldn't hesitate recommending WebAPI over WCF (actually I would recommend using Nancyfx over WebApi any day of the week).
You can expose your service as HTTP with about 10 minutes work using WCF, assuming you wish to expose the same operations as are currently defined on your service contract, as you have already have the soap endpoint.
Plus you will end up with a simpler solution without the considerable bloat of asp.net/owin.
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.
Good old Microsoft documentation at it's finest. Does anyone know of any resources that explains how to deploy Web Api with Asp.net Web Forms application. I have the web api in a separate class library and I call using jquery. I don't want anonymous users to be able to access this service only the application. Do I want to use self hosted? How do I lock the service down? Awesome examples showing how to use, tons of videos but nothing on deployment.
You don't have the right architecture for what you are describing, but what you have is right.
If you are calling web services from the client side (using jquery) then your web service must be public facing.
What you are describing is a web or WCF service in a service oriented architecture. That service would most likely live on a different server and be on an internal network, etc. Even if it's on the same server your requirement is that it is not publicly accessible - thus none of your jquery would work since that request is being initiated by the user and users can only make requests to public facing services.
The comments about using forms authentication to protect your service calls are right. jQuery will include the forms authentication cookie for you when it makes AJAX calls so you shouldn't have to change much on the client side.
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