I have created a C# project thats consists from a backend service running under LocalSystem account and a GUI running under current logged-in user account.
These two parts communicate through named pipe, implemented as:
SERVICE:
PipeHost = new ServiceHost(this, new Uri[] { new Uri("net.pipe://localhost") });
PipeHost.AddServiceEndpoint(typeof(IPipeComm), new NetNamedPipeBinding(), "MyProgComm");
PipeHost.Open();
GUI:
ChannelFactory<IPipeComm> PipeFactory = new ChannelFactory<IPipeComm>(new NetNamedPipeBinding(), new EndpointAddress("net.pipe://localhost/MyProgComm"));
IPipeComm PipeProxy = PipeFactory.CreateChannel();
All working sweet, but now i'm stuck at a new feature they asked me to add.
I must find a way to communicate with service (at least one-way towards service) from a mobile device, let's say Android, connected to the same LAN.
At first i thought about building a simple Android native app that would communicate with a TCP server added in service.
This requires some serious research from me, since i never did something like that before.
So allow me to ask:
Which is the easiest way to accomplish this?
Can i utilise the existed named pipe for such purpose to save time and coding?
Can this be done by adding a minimal web server, in order to avoid creating a mobile device app and just use its browser? (i'd really preffer that!)
I'm confused, so a couple of guidelines would be really appreciated...
One of the questions you are asking is whether your NetNamedPipeBinding will work in this scenario. It will not. WCF uses NetNamedPipeBinding for when the service is on the same machine as a process communicating with the service. That is not the case in the scenario you describe.
What you are asking about is fairly large topic, but here's one pointer to start with: try switching to using a BasicHttpBinding or a WSHttpBinding instead, since these can handle the scenario where the client is not on the same machine as the service. To get familiarity with this, you could perhaps focus on getting them running from code on a PC contacting your server first. Note, there are real security implications for whether you choose Basic vs WS bindings. You'll have to figure out what your security needs are and how to proceed. If this is an intranet, you may be able to get away with fairly simple security, but the fact that you are talking about a mobile device makes this sound more complicated.
Your next step will be to figure out how to get this working on a mobile device. If your mobile device is not a windows device, some of the ease of use of WCF will be lost. (On a windows device could probably still use a svcutil generated client to call your service). Here's where I think you may want to consider using a RESTful web service via WCF. Getting your Android app to talk to a Restful service is probably bit simpler than getting it talk to the service via a wsdl, but both will work.
Related
I have an application in WPF c# which will run on client machine. Another application (maybe some kind of service) on a particular server will be running all the time and will wait for any incoming message from the client app. As soon as the server receives a request from any of the client application, it triggers a command line process and also responds to the client about the staring info(whether it was successful or not) and as well as when the command line process is finished it again responds to the calling client application that it got finished.
I am new to in this area.
So my question is should I use normal windows service or Web service or WCF?(Some kind of link to a demo project will really help). Any other suggestion are also welcomed.
You did not mention if your clients will be outside of your firewall or with in the same intranet. We have intranet scenario, and we use WCF service that communicates with WPF based applications over the internal network. WCF provides Duplex feature which enables two-way client server communication using an easy to implement programming model. I recently wrote an article on this and it can give you a head start for the WCF way.
However, WCF does not have the best support for callbacks over the internet and you may have to look in to effectively using it in your case. But if it is intranet, then my suggestion is surely to go for the WCF way. Hope it helps.
I am a newbie developer to WCF and Windows services. I do know c#. The scenario requires various custom applications running on Windows 7 to call methods in another application. It is a client/server relationship, all running on the same computer. The server must be able to notify each client (one at a time) when a specified condition occurs.
I need to develop the server code only.
Would the following be an acceptable solution:
Make the server a windows service that uses WCF. The server could notify the clients by using a different named pipe for each client ?
Thank you...any suggestions would be appreciated.
Just use duplex communication over tcp/named pipes/msmq/http (WSDualHttpBinding) channel.
AFAIK you need two ports (in/out) for duplex over http
I would ditch wcf altogether. Although as Brian says, you can use the duplex bindings, these are complicated at best.
If it's all going to run on the same computer, why do you even need client/server? Just build a single client which does everything you need.
That is a acceptable solution and should work fine.
Other option for consideration (in the spirit of learning) is creating a Routing Service as an intermediary service which spawns the calls to multiple services. So in your scenario, your client would call the routing service and the routing service will in turn call each of your service
The following link should provide more information on routing service...
[Routing Service][1]
http://msdn.microsoft.com/en-us/library/ee517423.aspx
I need multiple clients that talk to a WCF service. The WCF service also must be able to connect to any one of the clients also.
So - it sounds like the server and the clients need to have both a WCF server and client built into each one.
Is this correct or is there some way to do this?
I was looking at NetPeerTcpBinding, but that is obsolete. To be fair I'm not sure if that is a valid solution either.
Background:
I plan to have a Windows service installed on hundreds of machines in our network with a WCF service and a WCF client built in.
I will have one Windows service installed on a server with a WCF service and a client built in.
I will have a Windows Forms application
I will have a database
The clients on the network will connect to the service running on the server in order to insert some information on the database.
The user will use the Windows Forms application to connect to the Windows service on the server and this Windows service will connect to the relevant client on the factory floor (to allow remote browsing of files and folders).
Hence I believe the machines on the floor and the server both require a WCF cleint and service built in.
The reason people are recommending wsHttpDualBinding is because it is in itself a secure and interoperable binding that is designed for use with duplex service contracts that allows both services and clients to send and receive messages.
The type of communication mentioned 'duplex' has several variations. Half and Full are the simplest.
Half Duplex: Works like a walkie-talkie, one person may speak at any given time.
Full Duplex: Like a phone, any person may speak at any given time.
Each will introduce a benefit and a problem, they also provide ways to build this communication more effectively based upon your needs.
I'm slightly confused, but I'll attempt to clarify.
You have an assortment of approaches that may occur here, a Windows Communication Foundation (WCF) Service requires the following:
Address
Binding
Contract
Those are essentially the "ABC's" for WCF. The creation of those depicts a picture like this:
As you can see the Service will contain:
Host
Service
Client
The host houses the service which the client will consume so those service methods perform a desired task. An example representation:
As you see Client-1 is going through the Internet (HTTP, HTTPS, etc.) then will hit the Host, which will have the service perform those tasks.
Now Client-n is consuming the service locally, so it is talking over (TCP, etc.) as an example.
The easiest way to remember: One service can be consumed by however many clients require those methods to perform a task. You can create very complex models using a service-oriented architecture (SOA).
All WCF is, is a mean to connect your application to a host or
centralized location you may not have access to.
As you can see in the above image, the Client communicates through a Service to the Host. Which performs a series of task. WCF will talk over an array of protocols. Hopefully this will provide a better understanding of how WCF is structured.
There are a lot of tutorials and even post to get you started. Some excellent books such as "WCF Step by Step".
Essentially your looking for an asynchronous full duplex connection, or a synchronous full duplex service. As mentioned above, your task in essence is the point of a Service.
The question: How does this work best?
It will boil down to your design. There are limitations and structures that you will need to adhere to to truly optimize it for your goal.
Such obstacles may be:
Server Load
Communication Path
Security
Multiple Clients Altering UI / Same Data
Etc.
The list continues and continues. I'd really look up tutorials or a few books on WCF. Here are a few:
WCF Step by Step
WCF Multi-Tier Development
WCF Service Development
They will help you work with the service structure to adhere to your desired goal.
Remember the "ABCs" for the most success with WCF.
Use wsDualHttpBinding if you want your service communicate with your clients.
Read WS Dual HTTP.
You might want to try out creating a WCF service using netTcpBinding. It will work for your requirements. You can use the article How to: Use netTcpBinding with Windows Authentication and Transport Security in WCF Calling from Windows Forms as a start:
Also, there are many examples included within the WCF Samples package which you can use.
I'm relatively new into communication between applications, my goal is to have a Windows Service and somewhat a Managment Application where I can tell the service what to do, which methods to run (remote function calling). I stumbled upon "remoting", but a lot of people are telling this technique is deprecated and it's better to switch to something called WCF.
By this, I build my service according to this MSDN document:
http://msdn.microsoft.com/en-us/library/ms733069.aspx
I can install the service, run it, close it. But how do I interact with it? How does an "WCF client" application has to look like? It seems like WCF is something completely different to remoting, there are no server-client interfaces, no marshalled objects. I'm a litte bit confused, hope you can help.
You need have a Proxy/ChannelFactory for the client to interact with your WCF service.
On the client side you need a App.config/Web.config where you need to configure the endpoints the client has to lookfor for the service. You can do this programatically also.
Just go through the basics of WCF its easy than you think of it. :)
http://msdn.microsoft.com/en-us/library/ms731067.aspx
I am using WCF to write a server that should be able to communicate with .Net clients, Android clients and possibly other types of clients.
The main type of client is a desktop application that will be written in .Net. This client will usually be on the same intranet as the server. It will make an initial call to the server to get the current state of the system and will then receive updates from the server whenever a value changes. These updates are frequent, perhaps once a second.
The Android clients will connect over the Internet. This client is also interested in updates, but it is not as critical as for the desktop client so a (less frequent) polling scenario might be acceptable.
All clients will have to login to use the services, and when connecting over the Internet the connection should be secure.
I am familiar with WCF but I am not sure what bindings are most appropriate for the scenario and what security solution to use. Also, I have not used Android, but I would like to make it as simple as possible for the person implementing the Android client to consume my services. So, what is my strategy?
with the small bit of android I have done.
the android sdk doesn't natively support soap server, you have to write it all your self.
Rest is your only option when working with WCF and android. Thats the way that Google are pushing you to develop apps.
WCF via HTTP transport is the way to go because it is not binary and does not make assumptions re all peers are .net/windows.
see this page for more info