I am trying to host a WCF service on a windows service.Basically WCF service reads the data from the back end database on the same machine.Now from the ASP.NET server on the same machine,I want to read the data that WCF service has read from Database.Can anyone suggest me the right approach to do this?? And also the binding that has to be used for the same.
It appears from your comments that your goal is to have different UI served by same WCF back-end. Here are few info with regard to binding:
For accessing WCF service on the same machine, the best binding would be named pipe binding. However, named pipe binding will not be accessible from other machines.
In case, you have to access the service from other machines, you should go for TCP Binding. Note that both named pipe and TCP bindings would be consumed from .NET client only (which should not be an issue for you).
Lastly, if you have to expose services over internet and/or they need to be interoperable, BasicHttpBinding or WSHttpBinding can be your choices. However, I would have different service interfaces for internal/private consumption and external/public consumption.
Finally, you can easily change the bindings via configuration, so you can select name pipe to start with and may change it to tcp binding in future. Further, its possible to have same service exposed on different end-points with different bindings.
Now, as far hosting WCF goes, you can host it in windows service or IIS. Advantage with IIS is that you have tested, scalable host that offer a quite few management options with UI. On flip side, with IIS (as web server), you cannot use named pipe or tcp binding. With newer windows server, you can even eliminate that dis-advantage with the help of WAS (Windows Activation Services).
Finally, have you considered using common in-process layer instead of out-of-process layer such as WCF? For example, you can have a common library (or set of libraries) that can provide business logic/data access with clear API. The same library can be used in different UI such as ASP.NET and window forms - the UI must use the interface and factories (or DI framework) for accessing the layer. Advantage is that you get performance gain due to in-process call. On flip side, the desktop client using in-process layer cannot be scaled easily or cannot be used over internet. WCF based application server solves these issue. I prefer creating in-process layer that will be used by server based UI such as ASP.NET while client based UI using WCF facade over the same in-process layer.
Using a WCF just to keep the code separate in case you wish or need to go for another UI is not very logical. What you could do is actually writing all the logic in a separate assembly. This you will eventually do when you implement it in WCF. WCF is just a hosting framework and will host the underlying assembly in an out-process host. If you have a single consumer of the service, and you wish to host it in the same machine (as in the post), it could have been used in-process. Your code-behind code can refer to the data access classes in the separate assembly. The same thing you do when you access the WCF service through the proxy.
From what I understand what you're trying to do would be something like this:
ASP.Net App --> WCF Service --> DB
The app calls a method on the WCF Service, which reads some data from DB and creates a report and send it back to the app. If this is the intent and both app and service are on the same machine then you can use named pipe binding which is pretty fast and is the preferred way of communication for systems on the same machine. You can also use the http binding which is more scalable. But the great advantage of WCF framework is that you can easily change bindings without affecting the functionality. So, I'd suggest you go with named pipes (net.pipe://) and later switch to Http, if required.
Related
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
We have binary WCF service (netTcpBinding) in a web-role and an asp.net website (to take advantage of SignalR over azure's backplane). Due to the extremely low budget, we want to host them both in a web-role (as website doesn't allow non-standard-HTTP(S) ports).
So is it feasible to host them both in a web-role, to keep the SignalR/web-interface capabilities but also use the binary WCF/netTcpBinding pattern?
Edit:
Maybe I should've asked in the first place "How to host both asp.net (for SignalR) and WCF (for netTcpBinding) in single web-role and wire them up to the hosting IIS?"
As long as socket binding does not conflict - I cannot see why that should not be possible.
See here:
What default port does WCF use for nettcp when hosted by IIS?
https://msdn.microsoft.com/en-us/library/ms731810(v=vs.110).aspx
I am in a stage of using SignalR in my project and i don't understand when to use Self hosted option and when we should not use. As a example if I am willing to host my web application in server farm,
There will be separate hosting servers
Separate SignalR hubs in each IIS server
If we want to broadcast message into each client, how this is working in SignalR
The idea with SignalR running in multiple instances is that clients connected on instance A cannot get messages from clients connected to instance B.
(SignalR scaleout documentation)
However, when you scale out, clients can get routed to different
servers. A client that is connected to one server will not receive
messages sent from another server.
The solution to this is using a backplane - everytime a server recieves a message, it forwards it to all other servers. You can do this using Azure Service Bus, Redis or SQL.
The way I see, you use the self host option when you either don't want the full IIS running (because you have some lightweight operations that don't require all IIS heaviness) or you don't want a web server at all (for example you want to add real-time functionality to an already existing let's say forms application, or in any other process).
Be sure to read the documentation for self-hosting SignalR and decide whether you actually need to self host SignalR.
If you are developing a web application under IIS, I don't see any reason why you would want to self-host SignalR.
Hope this helps. Best of luck!
I'm sure that was a confusing enough title.
I have a long running Windows service dealing with things happening in the world. This service is my canonical source of truth for the rest of my system. Now I want to slap a web interface onto this so the clients can see what is actually going on. At first this would simply be a MVC5 application with some Web API stuff. Then I plan to use SignalR 2.0 and Ember.js to make this application more interactive and "realtime".
The client communicates with the Windows Service over named pipes using WCF. A client (such as a web app) could request an instance of for example IEventService, would be given a WCF proxy client, and could read about events through this interface. Simple enough.
However, a web application basically just exists in the sense that it responds to requests from the user. The way I understand it, this is not the optimal environment for a long lived WCF client proxy to raise events in, and thus I wonder how to host my SignalR stuff. Keep in mind that a user would log in to the MVC5 site, but through the magic of SignalR, they will keep interacting with the service without necessarily making further requests to the website.
The way I see it, there are two options:
1) Host SignalR stuff as part of the web app. Find a way to keep it "long-running" while it has active clients, so that it can react to events on the WCF client proxy by passing information out to the connected web users.
2) Host SignalR stuff as part of my Windows service. This is already long-running, but I know nada about OWIN and what this would mean for my project. Also the SignalR client will have to connect to a different port than where the web app was served from, I assume.
Any advice on which is the right direction to go in? Keep in mind that in extreme cases, a web user would log in when they get to work in the morning, and only have signalr traffic going back and forth (i.e. no web requests) for a full work day, before logging out. I need them to keep up with realtime events all that time.
Any takers? :)
The benefit of self-hosting as part of your Windows service is that you can integrate the calls to clients directly with your existing code and events. If you host the SignalR server separately, you'd have another layer of communication between your service and the SignalR server.
If you've already decided on using WCF named pipes for that, then it probably won't make a difference whether you self-host or host in IIS (as long as it's on the same machine). The SignalR server itself is always "long-running" in the sense that as long as a client is connected, it will receive updates. It doesn't require manual requests from the user.
In any case, you'll probably need a web server to serve the HTML, scripts and images.
Having clients connected for a day shouldn't be a problem either way, as far as I can see.