I got a lot of theoretical answers from Google that WCF is better than Web Service etc. etc. But I want to know from the programming and implementation point of view. I am very new to coding and want to know that how do we implement all three of these technologies? How are they different and in which scenario we should used which technologies?
Thank you in advance.
A web service is an API that is hosted for access via a network connection - often the internet - and usually accessed over HTTP (or HTTPS).
WCF is a Microsoft .NET development framework that can be used to implement web services. That is, WCF-services are a subset of all web-services.
Windows services are a separate beast entirely: they are long-running programs that run on your local Windows machine, typically with no user interaction and on system accounts. They are used to handle many things in Windows, from low-level driver functionality to software updates.
You're really comparing apples and oranges. A web service is simply a program that you can "call" using the HTTP protocol. Typically, HTTP requests sent to the service contain some XML describing the method called and any parameters. The response from the service likewise contains XML with the return value and any output parameters. It's a little more complicated than this, but it gives you the basic idea.
Windows Communication Foundation (WCF) is a framework for building network services. You can use this framework to build web services if you wish. I suspect that what's tripping you up are the various Visual Studio project templates. You have one for WCF services and one for web services. The web service template builds a web service that runs inside of IIS. The WCF template gives you far more flexibility (you can make a web service as a stand-alone application, for example), but it is far more complicated.
If you're just beginning, I'd start with web service template and IIS-based web services.
MSDN is always a good reference:
Web Service Tutorial:
http://msdn.microsoft.com/en-us/library/8wbhsy70%28VS.80%29.aspx
WCF Tutorial:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
I think its always easier to learn by doing.
Good luck
Related
i was asked in an interview the following question about webapi
Why we need webapi?
I told "the services that are created in webapi can be used across wide range of devices like laptop, desktop, tablet and mobiles."
Then the interviewer asked why it cannot be done using web services and wcf?
I don't know the answer.
Can anyone let me know the answer.
Copying the title of your question into a search engine yielded the following link.
WCF and ASP.NET Web API
WCF is Microsoft’s unified programming model for building
service-oriented applications. It enables developers to build secure,
reliable, transacted solutions that integrate across platforms and
interoperate with existing investments. (ASP.NET Web API) is a framework
that makes it easy to build HTTP services that reach a broad range of
clients, including browsers and mobile devices. ASP.NET Web API is an
ideal platform for building RESTful applications on the .NET
Framework.
There is also a table detailing when you should use which.
I am working on creating a Windows 8 application. UI is using HTML5. Using WinJs I am calling a WCF service that returns a datatable used to build out the UI. All that is good.
I would also like to create a Window Service that gets packaged up with the application, so when someone download/installs it gets unpackaged and the windows service is started/executed. Is this type of configuration possible?
The WCF service today is a web service, but I would like to make it a windows service. The idea is to make everything self contained. This would allow me to make it available in the Microsoft Online store - if I wanted to go that route.
Windows 8 Applications don't support installing services. The best you can do is install a service separately.
Your WCF service should be decoupled from your app and most probably running on a different machine! I am pretty sure that the they are not going to allow you to install or run services in context of a Windows Store App.
Installing a windows service is not an ideal approach for any Windows 8 application. I understand that you want to make everythig self contained but, why as a WCF local service then? Why don't you consider having it has a data access layer in your app itself? Just a thought.
REGARDING CLIENT SIDE
Web services are separate projects and separate deployment models. You can have one Visual Studio project for the Windows 8 client app and one project for the Web Services side.
Windows 8 apps have several options for saving persistent data, such as endpoints for consuming web services.
There are several consideration when storing Windows 8 application data, such as the location of web services to be consumed.
Windows 8 Application data also includes session state, user preferences, and other settings. It is created, read, updated, and deleted when the app is running.
There are 3 types of dimensions to consider. The system manages these data stores for your app:
(1) local: Persistent data that exists only on the current device
(2) roaming: Data that exists on all devices on which the user has installed the app
(3) temporary: Data that could be removed by the system any time the app isn't running
As a developer, you concern yourself with a couple of objects to persist application data:
The first container object is ApplicationDataContainer. The other is ApplicationData. You can use these objects to store your local, roaming, or temporary data.
REGARDING SERVER SIDE
Your Windows 8 Client app will consume http-based web services.
Most developers deploy web services to the cloud to be consumed by iOS, Android, Windows, and other server side services.
Windows Azure is a cloud offering that makes exposing services to clients very simple.
You can leverage either cloud services for robust solutions or the lighter weight Azure Web Sites.
You can typically choose either of these two project types to create web services:
(1) Windows Communication Foundation WCF; or
(2) ASP.NET Web API, which is included with MVC version 4.
WCF has been around longer and has historically been the primary choice for developers when it comes to exposing services.
Microsoft's more modern concepts about web services relate to the ASP.NET Web API, which truly embracing HTTP concepts (URIs and verbs). Also, the ASP.NET Web API can be used to create services that leverage request/response headers, hypermedia, etc.
I'm currently developing a WP7 app, and I'd like it to talk with my SQL Azure database. I know there are currently two ways of doing it:
Talk to a WCF Service hosted on my web server.
Use oData to communicate with my database.
I don't know what's the pros and cons between the both of them, but I know that using the first method involves two remote calls: one: to the web server, and two: from the web server to SQL Azure. Would using oData allow me to directly communicate with my SQL Azure database? Does SQL Azure provide a REST interface for my WP7 client to work with?
If you use the WCF service approach and host the service on our web server (i.e. not in an Azure Web Role) then yes there will be two higher latency hops across the network. However the WCF service does have the benefit of allowing you to provide your own security approach for your mobile clients. I suspect that this app will be used by more than just a couple of people? If you take the approach of talking directly to the SQL Azure oData endpoint then you will really struggle with Authetnication and Authorization. It's not really designed for supporting your scenario.
The other thing to note with the SQL Azure oData endpoint is that it never left SQL Azure Labs; i.e. it was never actually shipped as part of the product and the Labs implementation is end of lifed and grandfathered to existing users only.
I know that doesn't really answer your question; the short answer is that there is no RESTful endpoint that you can access to talk directly to SQL Azure. The long answer is that even when there was one you probably didn't want to use it.
Without knowing more about your app it's a little hard to give guidance as to exactly what you should be doing. If you can provide a bit more detail I can provide some advice as to which Azure data storage technology would be best suited.
I need to migrate an ASP.NET application to Azure. The application needs database access and access to temporary files and also using out-proc COM objects. Turns out there's "Full IIS" mode that offers some rather vaguely phrased advantages (from here):
However there are a number of useful capabilities that only exist in IIS, including support for multiple sites or virtual applications and activation of WCF services over non-HTTP transports through Windows Activation Services.
Now obviously using Full IIS forces me to deal with the ASP.NET part and role part working in different processes and that's a big deal so I need to know whether I need Full IIS mode in the first place.
How do I decide if I need Full IIS mode? Is there a full checklist?
I think your default answer should be use Full IIS in Windows Azure capabilities. The hosted web core offering is really there for backwards compatibility as it was the original model prior to 1.3 SDK. Full IIS is the default and you must explicitly opt to go back to HWC.
The reasons that most people wanted full IIS were around a few, but important limitations:
Better support for IIS extensions (e.g. Smooth Streaming, Web Farm, ARR, etc.). HWC did not always support the modules and combined with a missing admin permission, made it really hard if not impossible to use all the modules that folks wanted to use.
Support for multiple web sites, vdirs, and application pools. HWC is a single app pool (the hosting process) and no way to support multiple web sites. There was a serious concern about needing to dedicate 1 entire role to a single web site. With Full IIS, you can have multiple sites and use host headers to get more bang for buck out of web role (especially with small web sites)
Support for standard tooling - Web Deploy, AppCmd, etc. don't work really well (if at all) with HWC. Anything that modified the applicationHost.config usually had issues with HWC.
WAS support. This allows you to use WCF with IIS as a host in non-HTTP transports.
In general, with Full IIS you have parity with what you do on-premises so it makes it much easier to configure and setup.
Regarding the RoleEntryPoint/HWC process model versus the RoleEntryPoint and separate Full IIS process, I am not sure that is really an issue. There were a few quirks perhaps initially, but what concerns you the most about this?
I have a WPF application that uses LINQ-to-SQL on a local .MDF file. This solution is simple, easy, and effective, i.e. I set up my model once, then read/write data anywhere via LINQ:
using (var db = Datasource.GetContext())
{
oldItem = (from i in db.Infos
where i.Id == TheId
select i).SingleOrDefault();
CreateForm(db, FormBase, oldItem, Button_Save);
}
What is the dead-simple equivalent of this for Silverlight apps?
Searching I find an explosion of terms:
WCF RIA Services, WCF Data Services (ADO.NET Data Services, Astoria), Data Services Toolkit
.NET RIA Services
OData(Dallas)
GData
REST, REST-based, REST-like, REST-inspired
XML, JSON, RDF+XML
web services, SOA
cloud-based services, Azure, SQL Azure, Azure Services Platform
All I want to do is this:
create an .mdf file
use some LINQ-to-SQL-like tool to generate a web-enabled (REST?) data layer etc.
ftp the .mdf file and classes up to my ASP.NET web hosting service
write silverlight clients that read and write to this data source with LINQ
Concentrate on learning RIA Data Services, or WCF Data Services. It converts your LINQ queries inside Silverlight to REST requests, and saves you from writing some of the infrastructure code. The whole idea is that your SL app communicates only to web services, you don't have access to physical DB, like when you're using some ORM (L2S). In SL, your are inside browser's sandbox, which prevents you from accessing file system, including db files.
Other approach is to write web service and expose data through it (GetArticleByID), and then you consume that services from Silverlight. Then you use LINQ to iterate on fetched, loaded data.
Here's what to do -
Create a Silverlight app using Visual Studio. You will get two projects, one with the Silverlight XAML, and the other a web application to host it.
In the web application, add your DBML (Linq-2-SQL) file. Configure as normal
In the web application, add a Silverlight enabled WCF service
In the WCF service, define some methods that access the L2S data context
In the Silverlight project, go to add Service Reference, hit "discover" and add the WCF service in
Instantiate the service, and access your methods
Sounds a little complex, but pretty straight forward in practice.
Not possible. Silverlight cannot access databases directly. Some sort of web service layer is required in between. I think WCF and RIA Services are the most widely used.
I would strongly recommend that you clear an hour in your schedule and just watch this video:-
net-ria-services-intro
In fact clear 2 hours and work along side the video building your own copy of the app being built.
If you want to develop a regular LOB (Line Of Business) Application, then you should follow the approach using a web service interface to your database. The RIA services or WCF data service is the current RAD (Rapid Application Development) technology by Microsoft to make this task easier.
If you're talking about a special scenario you need: Silverlight 4 when running out of browser can talk to COM servers on windows now. Talking to databases is described in this vast blog post: Cutting Edge Silverlight 4 Com Features.
If you're looking for a way to manipulate database-like files, you may take a look at the csharp-sqlite project. I think it compiles for Silverlight without much ado (quick and dirty proof of concept here: Proof of Concept csharp-sqlite in Silverlight). With it you could create and manipulate a database file in the user's isolated file storage in a regular Silverlight application and then upload it to wherever you desire.