Reputation: 199
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.
Upvotes: 1
Views: 1683
Reputation: 4654
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.
Upvotes: 1
Reputation: 15571
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.
Upvotes: 1
Reputation: 49185
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.
Upvotes: 1