Is there any difference between
Webservice and WCF
WCF and WCF RIA Data Services
it seems to be the same.
There are quite a difference between WCF and Web Service mostly in performance and security, also a flexibility and portability.
10 most important differences are listed right: HERE take a look!
A Web Service is programmable application logic accessible via standard Web protocols. One of these Web protocols is the Simple Object Access Protocol (SOAP). SOAP is a W3C submitted note (as of May 2000) that uses standards based technologies (XML for data description and HTTP for transport) to encode and transmit application data.
Consumers of a Web Service do not need to know anything about the platform, object model, or programming language used to implement the service; they only need to understand how to send and receive SOAP messages (HTTP and XML).
WCF Service
Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data.
Check this Link
Asp.net web services are homogenous.
Asp.net web services can use only HTTP chanenel.
Not supports msmq and tcp binding...
WCF is flexible because its services can be hosted in
different types of applications. The following lists
several common scenarios for hosting WCF services:
IIS
WAS
Self-hosting
Managed Windows Service
WCF = Web services + .Net Remoting + MSMQ + (COM+)
http://www.codeproject.com/KB/webservices/WCFVSWebService/WCFVsWebService.pdf
Related
Wikipedia says:
A Web API is an application programming interface for a web server (or web browser). And a Remote API is an application programming interface that allows developers to manipulate remote resources through protocols.
So, since Web APIs (e.g., Twitter APIs) are code snippets that developers use in their apps to access a web server's resource (via the HTTP protocol). Does this mean that a Web API is the same as a Remote API?
Or, are there any subtle differences?
I am creating a web app. I want to create a listening service (TCP) that listens continuously and updates web page according to that.
A Windows service or a WCF service?
At the end I just want a background service that listens on a socket continuously and update data in database. and when database is updated I will use signal r to show that in my page.
Right now I am trying with WCF but I am wondering if it can be done with Windows service also. And right now this application will work on LAN. But in the future, it can also be in the cloud.
First of all, it is important to understand that a Windows service and a WCF service are not the same.
A Windows service is a specialized executable that runs in the background on Windows.
A WCF service is a specialized piece of code that exposes some functionality through a well-defined endpoint. It does not run on its own, but instead must be hosted by some parent process, like IIS, a desktop application, or even a Windows service.
In thinking about the problem you've described, I suppose the most fundamental question to ask is whether or not you have control over the data that will be received via the TCP connection. WCF is built on the notion of the ABCs (Address, Binding, and Contract), all of which have to match in order to facilitate data exchange between WCF endpoints. For example, if you wish to expose a WCF endpoint via IIS that accepts TCP connections from some remote WCF endpoint, the remote WCF endpoint needs to send data to your IIS-hosted WCF endpoint using the agreed-upon data contract. Absent that, WCF will not work. So, if you cannot define the data contract to be used between WCF endpoints, then you'll need to find another option. An option that will work is to open a TCP listener within a Windows service, process the data as it is received, update your database, and listen for more data.
================================================
By way of example, I work on a project that has a front-end desktop application that communicates with a back-end Windows service. We build both the application and the Windows service, so we have full control over the data exchange between the two processes. At one point in time, we used WCF as the mechanism for data exchange. The Windows service would host a WCF service that exposed a NetNamedPipeBinding, which we later on changed to NetTcpBinding to get around some system administration issues. The application would then create its own endpoint to communicate with the WCF service being hosted within the Windows service.
This worked fine.
As our system got more mature, we needed to start sending more and more information from the Windows service to the application. If I recall correctly, I believe we experimented with streaming within WCF and concluded that the overhead was not something we could tolerate. So, we used WCF to exchange commands and status information between the application and the Windows service, but we simultaneously used a TCP socket connection to stream the data from the Windows service to the application.
This worked fine.
When we got a chance to update the Windows service software, we decided that it would be better to have a single communication mechanism between the Windows service and the application. So, we replaced WCF altogether with a TCP socket connection that uses a homegrown messaging protocol to exchange information in both directions - application to Windows service and Windows service to application.
This works fine and is the approach we've used for a couple of years now.
HTH
Lets say that I have multiple internal ASP.NET web api applications. i.e.
http://service1.something.com/bob/bill
http://service2.something.com/pete
http://service3.something.com/dancing/dragon
I would like to expose these different services under a common host name
http://something.com/service1/bob/bill
http://something.com/service2/pete
http://something.com/service3/dancing/dragon
The reason I'm thinking of this setup is to allow each service to run a different set of middleware, but give the client a uniform URL structure to use. Each service can then be upgraded indepently of the others.
Ideally this should be using the latest version of ASP.NET and potentially hosted on Service Fabric. It doesn't have to run on the new core stack, the full .NET framework is acceptable.
I've read that the WebListener supports port sharing, so that is something I'm considering.
Suggestions?
Yes, you can do this with ASP.NET applications in Service Fabric:
service 1: http://something.com/service1/bob/bill
service 2: http://something.com/service2/pete
service 3: http://something.com/service3/dancing/dragon
As long as you use a web stack that supports port sharing. On windows, that means using a web stack that uses the http.sys kernel driver. Here are the web hosting options currently available for ASP.NET on Service Fabric:
The WebListener host in ASP.NET Core 1 is based on HttpListener which uses http.sys, so that will work.
Kestrel in ASP.NET Core 1 is not based on http.sys and to my knowledge does not support port sharing, so that won't work.
Katana uses HttpListener so that will also work.
Even in Azure Fabric every service should have different port - port sharing is available for service replicas (statefull) or multiple instances of the same service (stateless).
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-service-manifest-resources/
Common way to have uniform URL structure is to create Api Gateway, which will call other services.
http://microservices.io/patterns/apigateway.html
Myself and my architect are designing the architecture for one of our products and he suggested to go with Web Api as a Service Layer (because it's a light weight component).
Straight away I'm thinking how it can be used for non-http based clients and also for external clients. How can we provide the proxy information about our API (in case the API is having a complex type as parameter)?
Please advice whether we can use Web API as Service Layer?
Straight away I'm thinking how it can be used for non-http based clients
Well, it can't. The Web API works only on top of the HTTP protocol. If you need to use some other transport protocols such as UDP you might consider WCF instead.
How can we provide the proxy information about our API
RESTful services do not have the notion of proxy information. They should be documented well for non .NET clients. For .NET clients you could share the contracts (Request/Response Dto) between your server and client application. The client application could then reuse those Dtos which may act as what you call proxy and which is something that exists in the SOAP world but not in the REST world.
There is a WCF Windows Service listening in netTcpBinding protocol, which I understand is Microsoft's proprietary protocol (correct me if i am wrong). I need to write a website that will consume the WCF services. I know for certain PHP can only connect to WCF Service in SOAP (basicHttpBinding or wsHttpBinding) so I need to write another SOAP proxy.
Some comments on the internet suggest that it is possible to have ASP.NET website connect to a WCF Service via net.tcp protocol. Is this actually true? Where should I look?
Your understanding about the netTcpBinding is correct. It is proprietary and accessible only from .NET clients. Since ASP.NET is .NET you could consume your WCF service without any problems.
Ofcourse an ASP.NET web application can connect to a WCF service using net.tcp binding but not over the internet! If the application and the service arn't on the same server or in the same intranet it will not work, you have to choose a HTTP binding.
From my comment below:
Yes net.tcp can work over the internet but not every circumstances it's not recommended (check it at MSDN) to use it. Ofcourse if the whole server control is our we can give it a try but if not (the application and service hosted by a 3rd party member) the chances are not so high to get it work (for example port blocking, the net.Tcp listener is disabled, net.Tcp port sharing is not working or disabled)