Can anybody tell me what is meant by web services?
How do they work?
and more information about it.
Web services are typically application programming interfaces (API) or web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. --Wiki
Wiki has a good article on Web Services, you'll find a load of information there.
http://en.wikipedia.org/wiki/Web_service
As Andrew Tanenbaum and Maarten van Steen say in Distributed Systems - Principles and Paradigms, 2nd Edition: "a Web service is nothing but a traditional service (e.g., a naming service, a weather-reporting service, an electronic supplier, etc.) that is made available over the Internet". The main idea is that you have a client application that can use services provided (published) by a server application.
There are a couple of important things you should look into: one is the directory service which stores service descriptions, which should adhere to the UDDI standard. Another thing is that web services are described by the means of formal language (WSDL). And last, but not least, you need to specify how communication takes place: SOAP is a widely (probably most well-known) protocol in this sense.
Also, as can be noticed, be really careful about the standards (protocols, formal description language etc.), when implementing web services.
The ideas above have been taken from the aforementioned book (Distributed Systems - Principles and Paradigms, 2nd Edition, Andrew S. Tanenbaum, Maarten van Steen, 2007). For more programming language oriented books, you can check "Java Web Services: Up and Running" by Martin Kalin, O'Reilly, 2009 (did not read this but it is by a good publisher and it is new) and I am sure there are a lot of other good books out there.
Web services are just like a kind of framework, that you access over the Internet. That can be used for authentication, single sign-on, data access, etc. For instance, imagine a Twitter client. It can be a web application, a desktop application, or a mobile application. They all need to authentify a user, get the timeline, get the user tweets, and allow the user to post a new tweet. The aplication receives the data from the user, and transmit it to Twitter, by their web service. This is done by calling an URL on twitter.com with some parameters, depending on the web service format (soap, rest, etc). Then Twitter can process the action.
Web services allows applications to use, interact with, and communicate with other aplications. That way, you van have many apps, but only one data source.
Fahrenheit to Celsius - Simple Example Web Service (ASP.NET)
You can get started with Web Services # W3Schools.com.
Your first C# Web Service - Code Project
And most of your questions are answered in a 15seconds article.
in web application web-service used for transfer data using Ajax technologies without refreshing all page.
also i prefer to you this article with sample Create a JSON WebService in ASP.NET 2.0 with a jQuery Client link text wroted by Ajay Singh link text
If you are familiar with calling a subroutine (method/procedure/function/etc) with parameters and get a result back, then "web services" is one of many ways to call a subroutine located "elsewhere" and get a result back. "Elsewhere" is typically on another computer under the control of somebody else but you.
It has been tried several times before but I believe that Web Services have become so popular due to several reasons:
The communication can be done over http (like a browser). This means that a lot of infrastructure can be reused, and as http is simple, that infrastructure can be simple. This includes proxies, firewalls, debug tools etc.
Web Services include a "contract" - WSDL - saying exactly which things are provided, where they are, and what arguments they take, and what is returned. That contract allows building helping tools, proxies, creating a tool that simulates the other end, and much more.
Microsoft likes it. This results in good support on Windows, which gives many programmers an easy way in.
But, the answer to your question is "web services are subroutines located on other computers".
Web services are typically application programming interfaces (API) or web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. isma
Related
I would like to add a password protected page to my WPF modernUI application and could use some help with it.
First of all I don't really have a clue how to handle this stuff correctly in my case.
My application is used on several machines. The protected page should be some kind of admin-page to edit a database that is used by the app.
My idea is, that there is only one Admin-account. But this account can be used from any machine. The admin should be able to change his password. So there must be some kind of encrypted password file on the server which can be accessed from any machine. I don't want to store the password within the application, as this would mean that the admin has to change his password on every machine.
So my question is: What is the best/safest solution for my idea? I'm just looking for hints as I don't have a clue what to search for.
The best Practise nowadays for distributed client applications who share a Database is indeed not to have direct access to the Database.
What you need is a WebService. A web service can be anything. It just has to be hosted somewhere. It can be an ASP.NET application, a WCF Service, or even something not .NET related like a PHP or Java application.
The communication between your application and your WebService depends on what you decide to use. Today a lot of people are using so called REST APIs which use either XML or JSON as data transfer format and use the HTTP protocol.
Its not hard to implement such an API since there are ton of Libs and Solutions out there.
You could use RestSharp for the communication at your client side. Which is straight forward and simple. You could also consume a WCF Service. Which is hosted in IIS somewhere.
However your Problem is nothing special and there are several solutions available. The decision is on your side since it depends on a lot of things such budget, available infrastructe etc.
Your question is quite broad but as far as WPF is concerned you could implement custom authentication and authorization in your application by creating classes that derive from the IIdentity and IPrincipal interfaces and overriding the application thread’s default identity. Please refer to the following blog post for more information an an example.
Custom authorization in WPF: https://blog.magnusmontin.net/2013/03/24/custom-authorization-in-wpf/
The actual credentials should be stored on some remote server that may be accessed through a web service, WCF service or some other kind of API. The details of how to actually get the credentails would be implemented in the AuthenticationService class in the sample code from the above link.
I have to come up with an integration process to allow existing system to use external data providers. The system is a medical timetable web site, using ASP.NET MVC, that allows the patients to schedule their appointments to doctors.
As far as I go you can see on a figure below:
All the providers must expose my contract ISuperIntegration which will be develop by me. I won't be developing External service 1 and External service 2, they will be developed by other companies.
Here the issue comes: basing on the concept of that I could require the way providers should setup their services to communicate with my website properly, I want to forbid for another third party clients consume "External Service 1" and "External Service 2", Or at least make it difficult to do that.
Here is a list of stuff I am setting:
ISuperIntegration interface. It contains operations related to my domain such as GetSchedule, GetDoctors and so on.
Transport protocol. I don't want it to be complicated so I'm thinking about using HTTP.
And could define some general recommendations but they could be easily avoided.
At the moment I'm thinking of using HTTPS with certificate authentication. It would require the implementer to setup their infrastructure so my web site could properly consume the data.
If I would go with basic HTTP, the implementer would just leave their service to be easily consumed by anyone else, which I don't want.
I hope my question is clear. Will be happy to give any other explanations you want.
I'll really appreciate any your responses, commits. Thank you!
I'd always use HTTPS for things like this. Let's just say that's the cost of doing business. You simply cannot have anyone with a sniffer grab that kind of traffic out of the sky. There's a reason why all banking etc. use HTTPS for things that should be secure.
Apart from that, web services have pretty standard mechanisms for security, I'd recommend looking at OAuth over HTTPS. There are plenty of implementations for that.
If your talking about basic web sites, I'd use a standard security mechanism as well like group based security (which boils down to a username + password). Again, there are plenty of implementations for that.
Basically my main word of advice is: don't go inventing stuff when it comes to security. If you're not an expert, you're probably going to get it wrong, and end up with something that can be intercepted by a third party or (much) worse.
You have several options:
Basic authentication over HTTP.
PRO. Easy to implemet
CON. UserCredentials was going in clear text throuh the network
Implement WS-Security with WCF. For example, they can sign their requests.
PRO. Easy to implement with WCF
CON. Java clients can faced with problems
You can force clients to use HTTPS.
CON. You should setup your web server.
You are like Oracle, they want people to develop in Java language but they also want to forbid competitors to run the Java compiled code on non Oracle's virtual machines, or at least make it difficult to do that :)
So you can do the same by protecting your interface with patent or copyright law. However, I doubt that it is patentable or copyrightable :)
Considering the privacy sensitivity of the data, IMHO it must be encrypted while in transport. Hence HTTPS not HTTP.
Authentication of your service to those providing services to you: well essentially it's up to them, not up to you who they expose it to, similarly how they want it protected is their call. Now assuming you do have a way to make them do the right thing...
Client certificates aren't that expensive nor prohibitive in setup to get up and running. But you do need to register the client certificate (every time it is renewed!) with the server in order to get the needed authorisation (just recognizing it's a valid cert isn't enough: anybody can apply for a (validly signed) certificate ...) .
But all that is relatively painless and rather well documented around the web, and it can be done on almost any platform of choice.
As several people mentioned these earlier you can't guarantee that those external companies will expose your service with specific security settings, it's up to them.
If you are responsible for developing MVC application and WCF service you can only force someone to use specific security settings on the layer between your WCF services and those External 1 and 2 providers.
Btw, here is a good tutorial that can be useful if you want to improve your knowledge about how to configure WCF security.
How External Services expose your service it's up to them. Just image that this is normal web 'proxy' behavior.
Maybe the architecture which your company adopted it is not the best for this solution
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.
I’m building a webservice and having some troubles witch option I should choose. Therefor I was hoping someone could point me in the right direction. I found many articles but none of them have more or less the options then I want.
What I want the webservice to do:
Client should get a WSDL derived from the ASMX file. Within that service there is one unauthenticated webmethod called “Authenticate(string Username, String Password)” that returns a custom AuthenticationSoapHeader. The AuthenticationSoapHeader is exactly and preferably same as the System.Web.Security.FormsAuthenticationTicket class that is used in the webapplication.
http://www.codeproject.com/Articles/4398/Authentication-for-Web-Services-using-SOAP-headers
http://www.codeproject.com/Articles/27365/Authenticate-NET-Web-Service-with-Custom-SOAP-Head
I’m thinking of using the articles above to implement this and changing the username password combination for a ticket that will be encrypted including a datetime stamp to expire the ticket. My questions.
Would this be considered a best practice? If not, what better option do I have.
Is using WSE3 “Microsoft Webservice Enhancement” necessary?
Is WCF a better option if your kinda new to webservices?
The soap requests go over Https SSL and do not need further encryption on the client side. Thank you in advance.
Best regards,
Danny
I can't answer all these questions, but I can answer a few: IMO WCF is all you need as a tool set for this project, based on your description. WCF has a number of different flavors (http, TCP, etc.) and each has several different options for how you implement security.
WCF has options for user/pwd authentication, or you can construct a custom method, or you can construct a Login() function that takes a UserID and Password as parameters, returning a boolean. There are also options that allow you to authenticate BEFORE the main program receives the request. That's what the built-in UserID/Password authentication does.
If you implement SSL on the host, assuming you're using an http-centric binding, you won't need anything on the client side for encryption as the WCF software will take care of that, once you have both the Host and Client software configured properly. In effect, your WCF client app will behave like a browser, handing all the nasty cert stuff under the covers.
WCF also lets you a) run your web service as a stand-alone windows service (called "self hosted"), or b) allows you to configure your web service behind IIS, which has some advantages. WCF will also provide a WSDL for your clients if needed.
There are some other nice things about WCF; if 10,000 concurrent users hit your web service at 8 am on Monday, WCF automatically queues the requests it can't handle, processing them in order as it can. I've slammed our testing web service with numbers like that, and the program never broke down, processing >150 logins and file uploads / second. WCF is also works fine with Java, iOS and Android.
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.